Mit Stand von heute, 10. Februar 2021, haben 2651 Spotify-Kunden eine Funktion namens „{iOS} Implement Native HomePod Support“ gefordert und für deren Umsetzung abgestimmt.

Doch Spotify kümmert sich nicht und tut – nichts. Zunächst schob Spotify die Schuld auf Apple, doch inzwischen hat Apple seit der WWDC im Juni `20 den HomePod für Streaming-Dienste von Drittanbietern wie Spotify geöffnet. Der Streaming-Dienst Pandora ist seitdem zum Beispiel auf dem HomePod verfügbar.

Wenn du ebenfalls vermisst Spotify auf dem HomePod nativ mit Siri zu steuern, so wie man Apple Music steuern würde, ist hier Eure Chance. Bringen wir Spotify dazu unsere Stimmen ernst zu nehmen!

1. Besuchen Sie die Feature-Request-Seite für die native Unterstützung von HomePod.
2. Melden Sie sich mit Ihrem Spotify-Konto an.
3. Klicken Sie auf das Zahnradsymbol, um einen Benutzernamen für das Forum einzurichten.
4. Gehen Sie zurück zu dieser Feature-Request-Seite und stimmen Sie für diese Funktion ab (Achtung, Sie können nicht abstimmen, ohne einen Benutzernamen zu haben, siehe Schritt 3).

Ich persönlich habe ihnen auch einen Kommentar hinterlassen, den Sie vielleicht kopieren möchten:

Apple allows this to work. Spotify doesn‘t care. That is the problem.
Ignoring this feature request further on will bring me to cancel my Spotify subscription and changing to Apple Music.
For me there has never been a reason to do so, but now there is.

Daniel

Der Beitrag Native Unterstützung für Spotify auf dem Apple Homepod erschien zuerst auf Pixelfriedhof.

Folgendes Szenario: Ihr verbindet Euer iPhone mit dem öffentlichen Hotspot Eurer Wahl, sagen wir in irgendeinem Café am Flughafen. Euer iPhone stellt die Verbindung her und fängt sofort an Accountinformationen, wie Eure E-Mail-Zugangsdaten über das unbekannte WLAN zu senden um die neusten Mails für Euch abzurufen. Eure eigentlich geheimen Zugangsdaten werden nun quasi für jeden lesbar in diesem öffentlichen WLAN übertragen und jeder der technisch in der Lage ist Eure Passwörter mitzulesen kann sich mit diesen nun auch in Euer E-Mailpostfach einloggen. Das ist natürlich kein wünschenswerter Zustand.

Abhilfe schafft hier die Nutzung eines sogenannten VPN-Tunnels. Der sichere und in sich gekapselte VPN-Tunnel wird von Eurem Endgerät zu Euch nach Hause (oder zu einem anderen sicheren Endpunkt) aufgebaut und sämtlicher Brauchdatenverkehr wie Mailaccounts, Chats, etc. erreicht erst vom Endpunkt des Tunnels das Internet. Der VPN-Tunnel ermöglicht somit das sichere Surfen, so als wäre man zuhause.

Wer schonmal versucht hat, seinen Datenverkehr des iPhones durch ein VPN zu schützen, der wird festgestellt haben, dass das iPhone nach einiger Zeit der aktiven VPN-Verbindung den Tunnel einfach beendet, zum Beispiel wenn längere Zeit keine Daten geflossen sind. Außerdem ist es ziemlich nervig den VPN Tunnel zuhause wieder manuell ausschalten zu müssen. Es gibt aber noch ein gravierenderes Problem: Um das VPN manuell anzuschalten, muss man zunächst mit dem WLAN verbunden sein. Noch bevor man also das VPN manuell verbinden könnte, hätte das iPhone in Sekundenschnelle im Hintergrund bereits Daten über ein eventuell unsicheres WLAN-Netz verschickt.

Damit das in Zukunft nicht mehr passiert, weisen wir unser iPhone an, in jedem unbekannten WLAN eine VPN-Verbindung aufzubauen, bevor es Daten verschickt. Das realisieren wir über sogenannte Profile. Profile sind im Grunde genommen Dateien mit (XML-)strukturiertem Inhalt, welche dem iPhone mitteilen wie es sich unter bestimmten Bedingungen zu verhalten hat. In der Regel werden diese Konfigurationsdateien im Firmenumfeld benutzt, damit man nicht tausende smartphones von Mitarbeitern manuell und händisch konfigurieren muss. Stattdessen verteilt man ein einziges Profil und verteilt es mit einem Klick an die Mitarbeiter-Geräte. Dabei erlaubt die Profilkonfiguration teilweise tiefere Eingriffe in die Einstellungen unseres iPhones als es das Einstellungsmenü zulässt. Und das machen wir uns zu Nutze.

Template mit Euren VPN-Daten anreichern

Der folgende Code ist ein Template für genau den oben beschriebenen Anwendungsfall. Genutzt wird in diesem Profil ein VPN vom Typ IPsec, wie es auch die FritzBox bereitstellt.

Sucht einfach nach „ÄNDEREMICH“ und ersetzt in diesen Abschnitten die Daten mit Euren eigenen VPN-Zugangsdaten.

Ihr braucht hierfür folgende Daten:

• Euren Hostname
• Username
• Password
• Shared Secret
• Liste von WLAN-Netzwerken, denen Ihr vertraut und welche keine VPN-Verbindung benötigen (Euer vertrautes Netzwerk am Arbeitsplatz oder Zuhause)

Tragt einfach alle Daten bis auf das Shared Secret als Klartext in die XML-Datei ein.
Euer Shared Secret packt ihr zuvor in diesen Generator (https://www.base64decode.org) und codiert das Shared-Secret somit auf BASE64. Das umgeschlüsselte Shared Secret tragt ihr dann in der passenden Stelle in die Datei ein.

Muss ich auch die Payloaddaten im Template anpassen?

Ihr werdet Euch möglicherweise fragen, ob Ihr auch die in dem Template enthaltenen Payloaddaten wie die PayloadUUID anpassen müsst. Auch auf diese Fragestellung will ich kurz eingehen und erkläre in diesem Abschnitt ein wenig den Hintergrund.
Eigentlich stellt Apple ein Programm bereit, mit dem sich Profile für iOS-Geräte erstellen lassen. Das Tool heißt Apple Configurator 2 und  ermöglicht die Erstellung von Profildateien über eine grafische Oberfläche. Wenn mit diesem Tool ein Profil generiert wird, werden automatisch die Payloaddaten generiert. Es handelt sich dabei mehr oder weniger um eine Art Zufallszahl, oder besser gesagt eine Prüfsumme, generiert aus verschiedenen Variablen des erstellten Profils.

Diese Zufallszahl ist sehr wahrscheinlich einzigartig, sprich es wird wohl kaum vorkommen, dass zwei Profile mit der exakt gleichen PayloadUUID auf einem Gerät installiert werden. Und das soll auch so sein, denn diese einzigartige UUID ermöglicht es uns später die Profildatei anzupassen und geändert erneut an das Endgerät zu schicken, ohne dass das Profil doppelt erstellt würde. Wenn bereits ein Profil mit der gleichen UUID auf dem Endgerät installiert ist, wird dieses lediglich upgedatet. Würdet Ihr ein Profil mit einer anderen UUID an das iPhone schikcen, würde es zusätzlich zum bereit vorhanden installiert werden, sprich ihr hättet ggf. doppelte Profile installiert.

TLDR: Nein, ihr müsst die Payload-Abschnitte der Profildatei nicht anpassen. 

mobileconfig-Datei abspeichern und an das iPhone schicken

Die Komplette Datei speichert ihr dann zum Beispiel als vpn.mobileconfig ab. Dabei ist besonders die Dateiendung „.mobileconfig“ wichtig.
Nach dem Editieren und Speichern schickt Ihr diese Datei per AirDrop oder E-Mail an Euer iPhone und installiert das erstellte Profil. Fertig.

mobileconfig-Datei zum Anpassen:

[code]<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE plist PUBLIC "-//Apple//DTD PLIST 1.0//EN" "http://www.apple.com/DTDs/PropertyList-1.0.dtd">
<plist version="1.0">
<dict>
<key>PayloadContent</key>
<array>
<dict>
<key>IPSec</key>
<dict>
<key>AuthenticationMethod</key>
<string>SharedSecret</string>
<key>LocalIdentifier</key>
<string>ÄNDEREMICHusername</string>
<key>LocalIdentifierType</key>
<string>KeyID</string>
<key>RemoteAddress</key>
<string>ÄNDEREMICHmy.hostname.de</string>
<key>SharedSecret</key>
<data>
ÄNDEREMICHABERCODIERMICHVORHERINBASE64
</data>
<key>XAuthEnabled</key>
<integer>1</integer>
<key>XAuthName</key>
<string>ÄNDEREMICHusername</string>
<key>XAuthPassword</key>
<string>ÄNDEREMICHpassword</string>
</dict>
<key>IPv4</key>
<dict>
<key>OverridePrimary</key>
<integer>1</integer>
</dict>
<key>OverridePrimary</key>
<true/>
<key>PayloadDisplayName</key>
<string>Manuelle Verbindung zum Heimnetz</string>
<key>PayloadIdentifier</key>
<string>com.apple.vpn.managed.D58846D4-51B5-437E-9147-199C811ABA1C</string>
<key>PayloadType</key>
<string>com.apple.vpn.managed</string>
<key>PayloadUUID</key>
<string>D58846D4-51B5-437E-9147-199C811ABA1C</string>
<key>PayloadVersion</key>
<integer>1</integer>
<key>UserDefinedName</key>
<string>Manuelle Verbindung zum Heimnetz</string>
<key>VPNType</key>
<string>IPSec</string>
</dict>
<dict>
<key>IPSec</key>
<dict>
<key>AuthenticationMethod</key>
<string>SharedSecret</string>
<key>LocalIdentifier</key>
<string>ÄNDEREMICHusername</string>
<key>LocalIdentifierType</key>
<string>KeyID</string>
<key>RemoteAddress</key>
<string>ÄNDEREMICHmy.hostname.de</string>
<key>SharedSecret</key>
<data>
ÄNDEREMICHABERCODIERMICHVORHERINBASE64
</data>
<key>XAuthEnabled</key>
<integer>1</integer>
<key>XAuthName</key>
<string>ÄNDEREMICHusername</string>
<key>XAuthPassword</key>
<string>ÄNDEREMICHpassword</string>
</dict>
<key>IPv4</key>
<dict>
<key>OverridePrimary</key>
<integer>1</integer>
</dict>
<key>OnDemandEnabled</key>
<integer>1</integer>
<key>OnDemandRules</key>
<array>
<dict>
<key>Action</key>
<string>Disconnect</string>
<key>InterfaceTypeMatch</key>
<string>WiFi</string>
<key>SSIDMatch</key>
<array>
<string>ÄNDEREMICHHeimnetzwerkname(SSID)</string>
<string>ÄNDEREMICHArbeitsplatznetzwerkname(SSID)</string>
</array>
</dict>
<dict>
<key>Action</key>
<string>Connect</string>
<key>InterfaceTypeMatch</key>
<string>WiFi</string>
</dict>
<dict>
<key>Action</key>
<string>Disconnect</string>
</dict>
</array>
<key>OverridePrimary</key>
<true/>
<key>PayloadDisplayName</key>
<string>Autoconnect zum Heimnetz in fremdem WLAN</string>
<key>PayloadIdentifier</key>
<string>com.apple.vpn.managed.85284094-A9F5-47D7-A1CD-6F831B2FFAC0</string>
<key>PayloadType</key>
<string>com.apple.vpn.managed</string>
<key>PayloadUUID</key>
<string>85284094-A9F5-47D7-A1CD-6F831B2FFAC0</string>
<key>PayloadVersion</key>
<integer>1</integer>
<key>UserDefinedName</key>
<string>Autoconnect zum Heimnetz in fremdem WLAN</string>
<key>VPNType</key>
<string>IPSec</string>
</dict>
</array>
<key>PayloadDescription</key>
<string>Es ermöglicht die manuelle, sichere Verbindung zum Heim-Netz in fremden, nicht sicheren WLAN-Netzen.</string>
<key>PayloadDisplayName</key>
<string>ÄNDEREMICH VPN Configurations for Organisation (z.B. Firmenname)</string>
<key>PayloadIdentifier</key>
<string>DB.BAB78424-28FB-4654-915D-93D0CB87CC7B</string>
<key>PayloadOrganization</key>
<string>ÄNDEREMICH Optional: Vorname Nachname für Name der Organisation (z.B. Firmenname)</string>
<key>PayloadRemovalDisallowed</key>
<false/>
<key>PayloadType</key>
<string>Configuration</string>
<key>PayloadUUID</key>
<string>8CADFABC-C196-4784-948E-FB5345714B22</string>
<key>PayloadVersion</key>
<integer>1</integer>
</dict>
</plist>[/code]

All the links in this text are Amazon Affiliate Links, and by clicking on an affiliate link I will earn a percentage of your subsequent Amazon purchases. However, this circumstance does not influence the background of my product recommendation. This product recommendation is independent, honest and sincere. 

Bei allen genannten Links handelt es sich um Amazon-Affiliate-Links. Durch einen Klick auf einen Affiliate-Link werde ich prozentual an Euren darauf folgenden Amazon-Einkäufen beteiligt. Dieser Umstand beeinflusst aber nicht die Hintergründe meiner Produktempfehlung. Diese Produktempfehlung erfolgt unabhängig, ehrlich und aufrichtig.

Der Beitrag iPhone: Erzwinge VPN-Verbindung in fremden WLANs erschien zuerst auf Pixelfriedhof.

Sie versuchen ein Projekt in Apple Logic zu speichern, zu exportieren oder zu bouncen, doch unmittelbar nach dem Klick auf den jeweiligen Menüpunkt stürzt die App ab. 

Ich habe herausgefunden, dass dieser Fehler dann auftritt, wenn die App Zugriff auf das Dateisystem erlangen will. 

Um das Problem zu beheben lassen wir Logic geschlossen, gehen in die Systemeinstellungen und deaktivieren dort unter den iCloud-Einstellungen die Funktion „iCloud Drive“.

Nun starten wir Logic erneut und das Projekt sollte sich wieder wie gewohnt speichern lassen.

Der Beitrag Lösung: Apple Logic stürzt beim Speichern, Exportieren oder Bouncen ab erschien zuerst auf Pixelfriedhof.

Users who use the SIP-telephone-app „Zoiper“ might experience a situation where outgoing calls can be made easily, but there won’t be a chance to answer incoming calls on the mac. Here we have the solution.

Im Falle des in der Einleitung beschriebenen Verhaltens muss ein einfacher Haken gesetzt werden, damit auch von außen ankommende Anrufe es bis zur Zoiper-App schaffen. So kann in einem Dialog ein eingehender Anruf angenommen, oder abgelehnt werden. Diesen finden wir unter den Einstellungen (Preferences)  im Reiter „Advanced“. Hier den Haken bei „Use rport“ setzen. In dem Drop-Down-Menü muss das Protokoll eingestellt sein, dass der SIP-Registrar verwendet. In einer AVM Fritz!Box ist dies standardmäßig UDP. Nun das Gerät neu regisitrieren und dann erneut probieren.

To avoid the situation described in the introduction, a box under „Preferences“ / „Accounts“ / „Advanced“ needs to be checked. Incoming calls will be forwarded to the Zoiper app and can be answered oder dismissed through a dialog. We set the checkbox „Use rport“. The linked drop-down-menu needs to contain the protocol used by the SIP-registrar. In case of an AVM Fritz!Box this is UDP by default. After correcting the settings, we register our device again and try to handle incoming calls with success.

Der Beitrag Zoiper: Keine eingehenden Anrufe auf dem Mac / No incoming calls on Mac erschien zuerst auf Pixelfriedhof.

In october 2015 we discovered an issue with Apple’s iCloud-Calendar. An event, based on a received invitation was not added to the default calendar, but to another calendar.
What first looks like a minor usability-problem, can be a major security-breach, if the faulty used calendar is shared or public and the event itself contains private information. A problem-solving approach.

English version see below.

Zunächst einmal sollte man meinen, dass der unter den Einstellungen hinterlegte Standardkalender für neue Termine auch der primäre Kalender für erhaltene Einladungen sei. Diesen Sachverhalt stellen wir für unseren Lösungsversuch in Frage und gehen nicht davon aus, dass dieser Zusammenhang korrekt ist.

Wir nehmen an, dass der in den Einstellungen des Kalenders hinterlegte Standardkalender ausschließlich die Zuordnung neu erstellter Termine regelt und deshalb neue Einladungen nicht im Standard in diesem Kalender abgelegt werden.

Die im linken Bereich des Kalender angezeigten Kalender lassen sich per Drag‘ n Drop in Ihrer Reihenfolge verschieben.
Wir vermuten nun, dass je nach Betriebssystemversion des Mac, entweder der oberste, oder der unterste dort angezeigte Kalender für die Ablage von Terminen benutzt wird, welche als Einladung empfangen werden.

Wir verschieben also den von uns gewünschten Standardkalender (in meinem Falle „Privat“, dunkelblau) an die oberste Stelle. Idealerweise ist dieser Kalender auch bereits in den Kalender-Einstellungen als Standardkalender hinterlegt, siehe ersten Screenshot.

Nach unserer Kenntnis ist das Problem damit behoben.

English version:

First of all, one might think, that the default calendar, configured in the calendar-settings, is also the default calendar for received events. For our approach to the problem we will question this statement.

We assume, that the defaultcalendar, configured in the calendar-settings, only controls, where new own-added events should be stored by default. We suppose that it just doesn’t control where events should be placed which were received through invitations.

The iCloud-calendars shown in the sidebar of the calendar-app can be moved in their order by drag’n drop.
Now we assume that, depending on the installed version of the Mac-OS, either the calendar on top, or the last calendar is used to store received events by invitation.

So now, we move our desired defaultcalender to the top, which in my case is the calendar „Privat“ in blue black. Ideally this calender is the same that is set as the defaultcalendar inside the settings-menu.

From our point of view, this solves the problem.

Der Beitrag iCloud: Einladungen zu Events landen im falschen Kalender / Events from invitations appearing in wrong calendar erschien zuerst auf Pixelfriedhof.