Wer bei seinem Windows 10 aufmerksam seine Einstellungen für den Datenschutz studiert, dem wird die App “App-Verbindung” auffallen. Sie taucht z. B. bei Position, Kamera, Kontakte und Kalender auf.
Schon seit letztem Jahr wird spekuliert, was es mit der App auf sich hat: http://www.howtogeek.com/247661/nobody-knows-what-windows-10s-app-connector-is-and-microsoft-wont-explain-it/. Oder http://superuser.com/questions/1003207/windows-10-what-is-the-microsoft-app-connector-and-why-would-it-want-need-acc. Die Officehilfe erwähnt die App sogar im Zusammenhang mit Synchronisationsproblemen mit Windows Mail oder Windows Kalender: https://support.office.com/de-de/article/Beheben-von-Synchronisierungsproblemen-in-den-Mail-und-Kalender-Apps-in-Windows-10-0dd86c69-18f3-4f73-9d3d-375bdc9c3e34. Wie so oft gibt es keine ordentliche Beschreibung von Microsoft oder vernünftige Quellenangaben.
Also versuchen wir mal die nötigen Infos selber zusammen zu tragen. Dabei kann man die prinzipielle Vorgehensweise hier für beliebige Apps unter Windows 10 verwenden.
Man kann sich mittels Powershell nähere Infos zur App holen, indem man
Get-AppxPackage -AllUsers |where name -eq "Microsoft.Appconnector"
eingibt, erhält man z. B.
Name : Microsoft.Appconnector
Publisher : CN=Microsoft Corporation, O=Microsoft Corporation, L=Redmond, S=Washington, C=US
Architecture : Neutral
ResourceId :
Version : 1.3.3.0
PackageFullName : Microsoft.Appconnector_1.3.3.0_neutral__8wekyb3d8bbwe
InstallLocation : C:\Program Files\WindowsApps\Microsoft.Appconnector_1.3.3.0_neutral__8wekyb3d8bbwe
IsFramework : False
PackageFamilyName : Microsoft.Appconnector_8wekyb3d8bbwe
PublisherId : 8wekyb3d8bbwe
PackageUserInformation : {S-1-5-21-XXXXXXXXXX-YYYYYYYYYY-ZZZZZZZZZZ-1001 [WIN\user]: Installed}
IsResourcePackage : False
IsBundle : False
IsDevelopmentMode : False
Von Interesse dabei ist der Installationspfad. Da kann man dann selber nachschauen, was die App so kann und macht. Jede App unter Windows hat eine Manifest-Datei, in welcher festgelegt ist, welche Zugriffsrechte die App möchte.
Also holen wir uns einfach doch mal diese Manifest-Datei:
$app=Get-AppxPackage -AllUsers |where name -eq "Microsoft.Appconnector"
$mf=[xml](Get-content "$($app.InstallLocation)\AppxManifest.xml")
In $mf steht nun der komplette Manifest-Dateiinhalt zur Verfügung. Durch die Verwendung des Typkonverters [xml] auch noch leicht verwertbar. Schauen wir uns mal einen Eintrag an:
$mf.Package.Applications.Application.VisualElements
DisplayName : ms-resource:ConnectorStubTitle
Description : ms-resource:ConnectorStubTitle
BackgroundColor : transparent
AppListEntry : none
Square150x150Logo : images\Logo.png
Square44x44Logo : images\AppConnectorAppList.png
SplashScreen : SplashScreen
Nicht sehr ergiebig oder? Allerdings ist ein Eintrag interessant, nämlich AppListEntry. Dieser ist mit None definiert und genau dieser ist es, warum die App nicht im Startmenü oder bei der Suche mittels Cortana auftaucht! Weitere Infos zu VisualElements bzw AppListEntry: https://msdn.microsoft.com/en-us/library/windows/apps/dn934817.aspx.
Neben VisualElements ist dann noch das Element Capabilities von Bedeutung:
($mf.Package.Capabilities).Capability
Name
—-
internetClient
picturesLibrary
videosLibrary
removableStorage
appointments
contacts
phoneCall
Es definiert, worauf die App Zugriff haben möchte. Also unsere unbekannte App möchte ins Internet, unsere Bilder und Videos anschauen können, auf Wechseldatenträger zugreifen, Kontakte und Termine sehen und zu guter Letzt noch die Anruferliste sehen. Also eine ganze Menge!
Aber das war noch nicht alles, sie will auch noch auf die Webcam zugreifen und Positionen abfragen:
($mf.Package.Capabilities).DeviceCapability
Name
—-
webcam
location
Zum Themenkomplex Capabilities findet man hier noch weitere Infos: https://msdn.microsoft.com/en-us/library/windows/apps/dn934741.aspx.
Für die Frage aber, was die App denn nun macht ist folgender Eintrag relevant:
$mf.Package.Applications.Application
Id StartPage VisualElements
– ——— ————–
App default.html VisualElements
Der sagt nichts anderes aus, dass wenn App-Verbindung gestartet wird, dass dann default.html aufgerufen wird. Also eine lokale Internetseite. Deren Inhalt kann man sich auch ganz einfach wieder anschauen:
Get-Content "$($app.InstallLocation)\$($mf.Package.Applications.Application.StartPage)"
und erhält:
<!DOCTYPE html>
<html>
<head>
<meta charset="utf-8" />
<title id="applicationName"></title><!– Connector.StubApplication references –>
<link href="/css/default.css" rel="stylesheet" />
/js/font%20style=
</head>
<body>
</body>
</html>
Also da passiert jetzt nicht so wahnsinnig viel. Allerdings könnte ja nun mittels default.js die Party abgehen. Also holen wir uns den Inhalt auch noch:
$html=[xml](get-content "$($app.InstallLocation)\$($mf.Package.Applications.Application.StartPage)")
Wir nutzen wieder den Typekonverter um das gewünschte Ziel schneller auslesen zu können. Denn wir sind an
$html.html.head.script
src
—
/js/default.js
interessiert, denn damit bekommen wir den Inhalt des Javascripts mittels
get-content "$($app.InstallLocation)\$($html.html.head.script.src)"
ausgelesen:
(function () {
"use strict";
function setTextContent(elementId, stringId) {
var resources = new Windows.ApplicationModel.Resources.ResourceLoader();
document.getElementById(elementId).textContent = resources.getString(stringId);
}function updateUserInterface() {
setTextContent("applicationName", "ConnectorStubTitle");
}document.addEventListener("DOMContentLoaded", function domContentLoaded() {
MSApp.terminateApp(new Error("This app should never load"));
}.bind(this));
})();
Das Javascript definiert eine anonyme Funktion und fügt dem Application-DOM einen EventListener hinzu, der darauf reagiert, wenn DOMContentLoaded ausgelöst wird. Aber jetzt kommt das Highlight, falls dies der Fall sein sollte, dann wird die App mit einer Fehlermeldung “This app should never load” abgebrochen!!
Ja was den nun? Für was gibt es eine App, wenn sie nicht geladen werden soll?
OK, manchmal gibt es ja Apps die sind für etwas Besonderes zuständig und haben gar keine UI, wie z. B. Dienste oder Proxys. Ist dies hier vielleicht der Fall?
$mf.Package.Extensions -eq $null
True
Also nix mit Extensions, nada niente.
Übrigens die fürs Wohlergehen zuständige Bing Health und Fitness App liefert z. B. so etwas:
$mfb.Package.Extensions
Extension
———
{Extension, Extension, Extension, Extension…}$mfb.Package.Extensions.Extension
Category ProxyStub
——– ———
windows.activatableClass.proxyStub ProxyStub
windows.activatableClass.inProcessServer
windows.activatableClass.inProcessServer
windows.activatableClass.inProcessServer
windows.activatableClass.inProcessServer
windows.activatableClass.inProcessServer
Hier die Beschreibung zu den Extensions und was da möglich ist: https://msdn.microsoft.com/en-us/library/windows/apps/dn934750.aspx. Um es gleich zu sagen, das ist eine Menge! Aber davon, wie gesagt, ist hier nichts gegeben.
Schauen wir noch auf einen weiteren interessanten Parameter, welche Versionsanforderungen die App hat:
$mf.Package.Dependencies.TargetDeviceFamily
Name MinVersion MaxVersionTested
—- ———- —————-
Windows.Universal 10.0.10069.0 10.0.10069.0
So so, hier wird also eine Buildnummer 10069 als Minimum genannt. Übrigens 10069 war eine Beta vor dem April 2015! Nun gut, bei Top-Programmen kann man das so stehen lassen. Witzig wird aber der Parameter MaxVersionTested. Der besagt, dass 10069 die neueste Version ist, mit welcher die App getestet wurde, was irgendwie null Sinn ergibt, denn es sind ja mittlerweile viele andere Versionen herausgekommen?!?!? Ist das aktives Qualitätsmanagement ala Microsoft?
Noch Infos zu den Dependencies: https://msdn.microsoft.com/en-us/library/windows/apps/dn986903.aspx.
Sei es wie es will, die App macht absolut keinen Sinn.
Übrigens taucht sie wieder an weiterer Stelle auf, wo man nicht unmittelbar mit ihr rechnet. In der Windows Firewall. Dort ist jede App registriert die mit dem Internet kommuniziert:
Get-NetFirewallRule | where DisplayName -eq "App-Verbindung"
Name : {F9CB7621-DFB0-4F00-BDB1-8D54D0D53710}
DisplayName : App-Verbindung
Description : App-Verbindung
DisplayGroup : App-Verbindung
Group : @{Microsoft.Appconnector_1.3.3.0_neutral__8wekyb3d8bbwe?ms-resource://Microsoft.Appconnector/Resources
/ConnectorStubTitle}
Enabled : True
Profile : Domain, Private, Public
Platform : {6.2+}
Direction : Outbound
Action : Allow
EdgeTraversalPolicy : Block
LooseSourceMapping : False
LocalOnlyMapping : False
Owner : S-1-5-21-XXXXXXXXXX-YYYYYYYYYY-ZZZZZZZZZZ-1001
PrimaryStatus : OK
Status : Die Regel wurde erfolgreich vom Speicher aus analysiert. (65536)
EnforcementStatus : NotApplicable
PolicyStoreSource : PersistentStore
PolicyStoreSourceType : Local
Wie kann man nun diese Ominöse App loswerden, ohne dass man jedes einzelne Einstellungsmenü durchgehen muss? Man verwendet einfach Remove-AppXPackage:
Remove-AppXPackage –Package $app.PackageFullName
Dadurch verschwindet die App aus allen Menüs wie bei den Datenschutz-Einstellungen. Schaut man sich aber den Installationspfad an, dann ist sie immer noch vorhanden, könnte also potentiell irgendeinen Blödsinn ausrichten. Also am besten entsorgt man das komplette Paket von der Platte:
$pro=Get-AppxProvisionedPackage -Online | where Displayname -eq $app.name
$proDisplayName : Microsoft.Appconnector
Version : 2015.707.550.0
Architecture : neutral
ResourceId : ~
PackageName : Microsoft.Appconnector_2015.707.550.0_neutral_~_8wekyb3d8bbwe
Remove-AppxProvisionedPackage -Online -PackageName $pro.PackageName
Path :
Online : True
RestartNeeded : False
So jetzt ist endlich Schluss mit dem Schrott. Zum Abschluss muss ich noch einen Ablassen über die Officesupport-Artikel…
Das nie endende Chaos! 
Hinterlasse einen Kommentar