Diskussion:Teamviewer/Archiv

aus Wikipedia, der freien Enzyklopädie

Diskussionsseite nicht Löschen

Diese Diskussionsseite nicht löschen! (nicht signierter Beitrag von 94.217.232.89 (Diskussion | Beiträge) 20:22, 13. Jun. 2009 (CEST))

Artikeländerung

  1. es gibt die vollversion, die registrierte vollversion (einziger unterschied zur noncomerz: die "buddyliste"?), die kundenversion (server ohne installation) und die portable version.
  2. es geht auch vollkommen ohne installation (server führt die TeamViewerQS_de.exe aus, der client Startet (nicht installieren) die TeamViewer_Setup_de.exe und der serverbenutzer gibt dem clientbenutzer seine id/passwort)!
  3. wie erfolgt die verbindung? client/server melden sich am teamviewerserver, um "ala dyndns" zueinanderzufinden? die direkte fernwartung geschieht dann per direktverbindung? Dateiübertragung/chat auch direkt oder geht alles über den teamviewerserver?
  4. host nennt sich in den neueren versionen "windowsservice"
  5. das einfachste tool seiner art (meine ganz persönliche meinung nach vnc, vncclones, xp-remoteunterstützung, kein gewurschtle in irgendwelchen soft/hardwarefirewalls, ...)
  6. nachteile? wenn ja welche? (unter xp-rechnern hab ich noch keine gefunden)
  7. kinder/oma/opa-leichte bedienung: 5 min telefon bei der "installation" und jeweils 2 min zur bekanntgabe des passwortes, die id bleibt immer gleich, dank aliases ist die liste immer überschaubar.
  8. zur zeit rundumzufrieden bin :-) --84.185.101.201 15:33, 10. Feb. 2009 (CET)

Denial of Service

Hier scheint jemand eine Debatte um ein Denial_of_Service anzufachen, obwohl das in diesem Zusammenhang falsch und irreführend ist. Der DOS-Angriff zielt auf die Lahmlegung eines Hosts indem er mit Anfragen überschüttet wird. Der Teamviewer Brute-Force-Schutz Brute_Force beschreibt die Tatsache, dass ein Angriff auf einen Client stattfindet und man nicht damit bezweckt diesen lahmzulegen, sondern seine Daten auszuspionieren. Der Brute-Force-Schutz verhindert ein knacken des Passwortes mit roher Gewalt- mehr nicht!94.217.232.89 20:22, 13. Jun. 2009 (CEST)Ralf

Sorry, sehe den Eintrag auf der Diskussionsseite erst jetzt - hier ist ja auch ein wenig mehr Platz als in der Zusammenfassung :-)
Also: Ich denke, es ist offensichtlich, dass ein Teamviewer, der auf Verbindungen wartet, einen Dienst anbietet. In dem Sicherheitsstatement steht nun, dass der Dienst vorlaeufig keine Verbindungen mehr zulaesst, wenn man ein paar erfolglose Loginversuche vornimmt. Damit ist der Dienst, ueber den man Fernadministration machen wollen koennte, nicht mehr verfuegbar. Insofern waere DoS schon erfuellt.
Man kann das ganze auch anders herum betrachten: Die Software ist halt kuenstlich so gebaut, dass sie sich sehr leicht ueberlasten laesst - da das Auftreten der Dienstverweigerung kausal mit der Last verknuepft ist, tritt der DoS also bei "zu grosser Last", also bei "Ueberlastung" auf. Das wuerde dann auch Deinen Anspruechen an einen DoS gerecht.
Kern der Sache ist also, dass nicht wesentlich ist, ob die jeweilige Funktionalitaet mit der Absicht gebaut wurde, einen DoS zu erzeugen, sondern alleine, ob ab einer gewissen (geringen) Last eine nicht-Verfuegbarkeit des Dienstes eintritt, und ob es moeglich ist, diese Empfindlichkeit gegen Ueberlast zum Lahmlegen des Dienstes zu nutzen.
Mal davon ab, dass auch der DoS-Artikel dies unterstuetzt: Auch z.B. Advisories zu Pufferueberlaeufen, die keine beliebige Codeausfuehrung zulassen, aber die Bearbeitung weiterer Requests verhindern, z.B., weil sich der Prozess bei Ausnutzung beendet, werden als "DoS-Verwundbarkeit" klassifiziert.
Ich verstehe, dass diese DoS-Verwundbarkeit eingebaut wurde, um Brute-Force-Angriffe abzuschwaechen ("verhindern" waere wohl das falsche Wort, da ein Brute-Force-Angriff ja nicht folgenlos bleibt, sondern anstelle einer Kompromittierung des Systems eine nicht-Verfuegbarkeit des Dienstes verursacht, was ebenfalls ein Sicherheitsproblem sein kann). Dies unterscheidet sich deutlich vom ueblichen Vorgehen bei oeffentlich exponierten Angriffsflaechen, die Angriffskosten fuer Brute-Force durch entsprechend hohe Authentisierungsentropie so hoch zu treiben, dass ein Angriff zwischen unwirtschaftlich und undurchfuehrbar wird, weshalb eine Erwaehnung dieser ungewoehnlichen und in Sicherheitshinsicht bedenklichen Implementierung sinnvoll scheint. Den Hintergrund der Sicherheitsluecke zu erklaeren, hatte ich im Sinne der Neutralitaet in meiner letzten Bearbeitung uebernommen. 85.116.198.153 01:01, 17. Jun. 2009 (CEST)

Ich denke, du kannst nicht von einem DOS reden, wenn für eine Person der Dienst ausfällt, welche "zufällig" 24mal das falsche Passwort eingegeben hat. Das ist meiner Meinung nach ein sehr guter Schutz aller Nutzer, dass ihr Bildschirm nicht einfach für alle offen steht. Klar ist für die Person, welche den Bruteforce Versuch gestartet hat, der Service nicht mehr erreichbar, aber eine solche Zahl an passwortabfragen führt man ja nicht aus Spaß durch! Da steckt leichte Kriminelle Energie dahinter, welche durch den TeamViewer unterbunden wird. Meiner Meinung nach voll ok, denn für alle anderen ist der Dienst ja weiterhin verfügbar. Missbrauch führt zum Ausschluss der Nutzung...Auch von anderen Services ein gern genommener Schutz! 77.25.221.129 12:10, 25. Jul. 2009 (CEST)

Kennst Du die Mechanismen im Detail? Dann erklaer doch bitte mal genau, wie dieser Mechanismus funktioniert, ibs. wie die Wartezeit bzw. die Ablehnung bei einem bestimmten Request ermittelt wird, und sorg dafuer, dass dies auch auf der Seite des Herstellers dokumentiert wird. Aus der oeffentlich verfuegbaren Dokumentation geht nicht hervor, dass die Loginbeschraenkung sich auf einen einzelnen Client bezieht, sondern vielmehr scheint das Login auf dem jeweiligen Server komplett deaktiviert zu werden. Da auch nicht ersichtlich ist, wie die Identitaet des Clients zuverlaessig ermittelt werden koennte, ist auch kaum etwas anderes vorstellbar. Somit ist davon auszugehen, dass bei Greifen des Brute-Force-Schutzes der Dienst komplett nicht-verfuegbar wird. (Oder aber alternativ kein Brute-Force-Schutz besteht, wenn die Identitaet, nach der er filtert, faelschbar, da prinzipbedingt nicht beweisbar, ist). 85.116.198.153 13:57, 29. Jul. 2009 (CEST)
Naja, mach einfach den Test. Versuch dich zu verbinden, gib ein paar mal ein falsches Passwort ein...Daraufhin kannst du dich ja trotzdem noch mit nem anderen Rechner verbinden. Die Identifizierung kann doch ganz einfach über die ID die jeder TeamViewer hat erfolgen. Damit verknüpft er ja auch irgendwie deine IP mit deiner ID. Ansonsten wären ja gar keine Verbindungen möglich. Die müssen dich schon identifizieren können. Und dann können die auch wohl einzelne IDs für bestimmte Zeit sperren...Warum nicht? 77.25.182.54 20:50, 29. Jul. 2009 (CEST)
Koenntest Du bitte ganz konkret die Mechanismen erlaeutern, die eingesetzt werden, und wie diese die von dir beschriebenen Eigenschaften sicherstellen? Deine Argumentation so anzugreifen, ist einigermassen witzlos, da sie zwar haufenweise Luecken enthaelt, aber ja sowieso nicht auf dem Produkt basiert, das hier beschrieben werden soll. Einen zentralen Punkt, an dem Deine Argumentation scheitert, will ich aber dennoch herausgreifen: Das ganze Problem, um das es geht, ist, die Identitaet des Gegenuebers zu pruefen (== Authentifizierung). Eine Begrenzung der Versuche pro Zeit soll vermeiden, dass dieser Pruefungsvorgang durch Brute-Force umgangen werden koennte, eine Identitaet also falsch bewiesen werden koennte. Und nun schlaegst Du vor, man sollte, um zu vermeiden, dass dieser Mechanismus zu einem DoS fuehrt, doch einfach die Identitaet des Angreifers pruefen, um den Dienst nur fuer den Angreifer zu sperren. Damit waeren wir dann wieder beim Ursprungsproblem: Der Identifizierung des Gegenuebers, damit nicht ein Angreifer sich als ein anderes Gegenueber ausgeben und so fuer das falsche Gegenueber den Dienst unverfuegbar machen kann. Ist der jetzt wieder per Brute Force anzugreifen, oder sollen wir da wieder nen Brute-Force-Schutz vorbauen, der DoS-verwundbar ist? 85.116.198.153 02:41, 5. Aug. 2009 (CEST)

Verbindungsaufbau

Kann jemand, der die Software kennt, den Verbindungsaufbau schildern?

Insbesondere den Teil, wenn beide Geräte hinter Firewall/NAT sind? Irgendwie muss die Verbindung ja über eine zentrale Stelle vermittelt werden.

-- Jackobli 14:39, 17. Sep. 2009 (CEST)

Sicherheit

Leute, es geht mir allmaehlich echt auf den Sack, dass dauernd Leute, die offensichtlich keine Ahnung von IT-Sicherheit und keine Ahnung von Kryptographie haben, meinen, sie muessten jetzt versuchen, wahrscheinlich nicht vorhandene Sicherheit in diesem Produkt zusammenzuphantasieren. Die vermeintliche Beschreibung, wie die Kryptographie hier zu Sicherheit fuehren soll, ist einfach nur abstrus. Ich wuerde daher darum bitten, dass nur noch Leute Aenderungen in der Hinsicht durchfuehren, die mal mindestens in Grundzuegen erklaeren koennen, wie so eine X.509-Hierarchie funktioniert und wo die wesentlichen Maengel von X.509 liegen, wie es heute z.B. im Onlinebanking angewandt wird. Werbung ohne jede Faehigkeit zur fachlichen kritischen Beurteilung abzuschreiben ist, denke ich, nicht, was zu einer verlaesslichen Enzyklopaedie fuehrt.

85.116.198.153 07:31, 11. Okt. 2009 (CEST)

Die Möglichkeiten die du aufzeigst sind stark hypothetischer Natur und beeinträchtigen die Sicherheit der Verbindungen mit TeamViewer nicht. Desweiteren scheinen solche Konstrukte hier deplaziert, da die Leser fortgeschrittene Kryptographiekenntnisse haben müssten um zu verstehen worum es in dem Artikel geht.

Altalavista 13:14, 15. Okt. 2009 (CEST)

Hast Du dafuer irgendwelche Belege (dass die Moeglichkeiten "stark hypothetischer Natur" sind, und dass das irgendeine Relevanz fuer die Sicherheit des Produkts hat)? Hat hier ueberhaupt irgendwer eine Quelle, die die Funktionsweise des Kryptoprotokolls beschreibt? Das Sicherheitsstatement vom Hersteller gibt ja nicht wirklich viel her (ausser einem Haufen Buzzwords) und ich stochere auch ziemlich im Dunkeln.

Und ja, ich hatte ja urspruenglich vor allem den Hinweis eingefuegt, dass Teamviewer dokumentierterweise ein DoS-Problem hat, was von irgendwelchen Schlaumeiern angegriffen wurde, die dann irgendwelche hanebuechenen Erklaerungen fuer die vermeintliche Sicherheit eingebaut haben. Da ich nicht einfach die Aenderungen immer wieder reverten wollte, habe ich dann halt angefangen, die Argumente im Artikel zu widerlegen. Der derzeitige Zustand ist wohl fuer den absoluten Laien unverstaendlich, und mit ein wenig Grundlagenwissen in Sachen Kryptografie entnimmt man dem Text im wesentlichen, dass der Autor wohl eigentlich ein anderes Fachgebiet hat. Vor allem faellt auf, dass dauernd mit "Echtheit" hantiert wird, aber der Text verliert kein Wort darueber, welche Identitaet ueberhaupt geprueft werden soll.

85.116.198.153 06:52, 24. Okt. 2009 (CEST)

Stark hypothetischer Natur deshalb, weil der gefälschte PublicKey irgendwie durch einen Dritten herausgefunden werden müsste. Das heisst die Hardwareinformationen des Rechners dessen Identität man dem TeamViewer Server vorspiegeln will, müssten bekannt sein. Durch eine virtuelle Maschine kann man zwar unterschiedliche Hardwareprofile simulieren, man müsste aber wissen welche Hardwaremerkmale zu einer bestimmten ID gehören. Desweiteren ist das keine sicherheitsrelevante Diskussion, da in dem Fall in dem man falsche Hardwaremerkmale vorspiegelt ein DOS herbeigeführt werden könnte, was zu einer Ablehnung der Verbindung durch die TeamViewer Server führen würde. Was man damit erreichen würde ist, dass man einen anderen User temporär geblockt hätte. Altalavista 17:49, 4. Nov. 2009 (CET)

OK, damit hätten wir jetzt also geklärt, dass Teamviewer wohl keinen Brute-Force-Schutz hat und dass ein DoS gegen fremde Identitäten möglich ist. Könntest Du vielleicht zu den ganzen "Fragen", die ich erstmal im Artikel selbst untergebracht habe, erhellendes beitragen? Wirklich toll ist der Abschnitt ja so immernoch nicht, aber da mir die Informationen fehlen, um das inhaltlich aufzufuellen und auszuformulieren, scheint es mir soweit sinnvoller, die Anmerkungen drinzuhaben, die auf Fehler hinweisen, als eben die Fehler einfach so stehen zu lassen. Alternativ koennte man einfach alle unklaren und fehlerhaften Sachen in dem Abschnitt löschen - aber vielleicht ist es sinnvoller, sich so allmaehlich einer nachvollziehbaren und sachlich korrekten Darstellung der Sicherheitsfeatures und ihrer Funktionsweise, und natuerlich auch ihrer Maengel, anzunaehern? Achja: welche Hardwaremerkmale fliessen in die Identitaetspruefung eigentlich mit ein? 85.116.198.153 07:40, 6. Nov. 2009 (CET)

Habe den Stand mit meinen Anmerkungen drin mal erstmal unten gesichert. 85.116.198.153 14:53, 6. Nov. 2009 (CET)

Der durch den Kleinkrieg einiger benutzer entstandene Abschnitt zur Sicherheit ist absolut unlesbar. Ich arbeite im IT-Support der Uni Hamburg und wollte mittels des Artikels einen Ersteindruck vom Programm gewinnen ehe ich mich näher damit auseinandersetze, ob wir es zur Fernwartung einführen. Allerdings ist der Abschnitt "Sicherheit" ein wildes hin und her in der Manier "so geht das, nein so geht das doch nicht, ja wohl geht das so, nö!". Tragt euren Flamewar doch bitte hier aus anstatt den Artikel damit vollzumüllen. Das hat darüber hinaus, dass keiner sowas lesen kann/will den großartigen Effekt, dass beide Seiten ihren Standpunkt nicht kommunizieren können, weil keiner versteht, was zum Henker eigentlich Sache ist. Danke. Zhokar 11:49, 29. Jun. 2010 (CEST)

Entwurf

TeamViewer nutzt eine Verschlüsselung auf Basis eines RSA Public-/Private-Key-Exchange und AES (256 Bit) Session-Encoding.[entwurf 1]

Nach Angaben des Herstellers sind Man-in-the-middle-Angriffe nicht möglich. (Vorsicht: die TeamViewer-Server selbst können solche Angriffe natürlich problemlos durchführen, indem sie ihren eigenen public-key an beide Kommunikationspartner übermitteln! Ich habe nichts in der Herstellerdoku gefunden, das dem widerspricht, bitte belehrt mich) Dies soll durch den signierten Schlüsselaustausch von zwei Schlüsselpaaren gewährleistet werden. Dabei wird der öffentliche Schlüssel (Public Key) (welcher?) direkt(!) ausgetauscht und damit der symmetrische Schlüssel (AES 256 bit) (welcher?) generiert. Die Public Keys werden über den Rootserver ausgetauscht (also doch nicht direkt?), der die Echtheit (Echtheit von was?) per Signatur mit dem Rootzertifikat bestätigt (welches Rootzertifikat? Und wie kann man mit einem Zertifikat signieren?). Der Public-Key des Rootzertifikats (Aber nicht das ganze Zertifikat? Wozu ist das Zertifikat dann gut?) ist den Clients bekannt, die damit die Echtheit der Signatur (die welche Aussage signiert?) prüfen. Somit gibt es eine sichere Kette (von wo nach wo?), die den Clients bestätigt, dass ein Public Key zu einer bestimmten ID gehört (und wie funktioniert das Binding der "ID" an den Benutzer?).

Die Identität der Clients soll angeblich anhand von Hardwaremerkmalen identifiziert werden, was aber natürlich vollkommener Quatsch ist, da Entitäten, die keinen physischen Zugriff auf einen Rechner haben (ibs. also dem Gegenüber oder etwaigen Servern der Firma Teamviewer), keine Eigenschaften dieser Hardware bewiesen werden können, sofern nicht Trusted Computing-Features wie die Remote Attestation durch ein Trusted Platform Module verwendet wird - das TPM wurde gewissermassen überhaupt erfunden, weil derartiges ohne nicht möglich ist. Anhand welcher Hardwaremerkmale die Identifizierung stattfindet ist nicht bekannt. Die TeamViewer Server "kontrollieren diese ID bei jeder Verbindung auf Gültigkeit"(was für eine Gültigkeit?).[entwurf 2] Prinzipiell ist es jedoch vorstellbar z.B. durch virtuelle Maschinen (als anschauliches, jedem sofort einleuchtendes Beispiel - für einen effizienteren Angriff würde man wohl einfach die Client-Software durch eine eigene ersetzen, die einfach keine "Hardwareprüfung" durchführt), dass ein falscher Key an den Rootserver übermittelt wird (was also heisst, dass die Prüfung von Hardwaremerkmalen nur funktioniert, solange man sie nicht zu umgehen versucht). In diesem Fall kommt jedoch einfach keine Verbindung zustande, da der gefälschte PublicKey nicht zum Private Key des eigentlichen ID-Inhabers (s.o.: wie funktioniert das Binding zwischen dem Schlüssel und dem "eigentlichen" Inhaber?) passt und die Verschlüsselung damit nicht initiiert werden kann. Somit ist durch vorgespielte Hardwareinformationen eventuell ein DOS, jedoch kein Man-in-the-middle Angriff möglich (non-sequitur).

Da Brute Force Angriffe gegen die Passwörter der TeamViewer Nutzer zu exponentiell verlaufenden Wartezeiten für die angreifende Identität führen, könnte durch das Vorspielen einer falschen ID ein Client für weitere Verbindungen gesperrt werden. Durch den Brute Force Schutz benötigt die angreifende Identität bereits nach 24 Fehlversuchen der Passworteingabe eine Wartezeit von 17 Stunden bis zum nächsten Versuch. Ein Zugriff auf einen entfernten Client ist auch mit falsch vorgespiegelten Hardwaremerkmalen nicht möglich, da die Autorisierung dafür fehlt (hae? Merke: Autorisierung ungleich Authentisierung!). Da laut Auskunft eines Teamviewer-Mitarbeiters[entwurf 3] die Versuchsbegrenzung jeweils nur auf die angreifende Identität wirkt, besteht vermutlich entgegen der Darstellung im Sicherheitsstatement des Herstellers kein Brute-Force-Schutz, da beliebig viele Identitäten erzeugt werden können (s.o.), die jeweils erneut einige Loginversuche mit voller Geschwindigkeit vornehmen können.


(Bis hierher stammt der Abschnitt von 85.116.198.153) eingefügt von w-alter 15:44, 24. Mär. 2011 (CET)


Also, ihr (die Wisser wissen schon ;) habt alle einen Sockenschuss. Das hier ist eine Enzyklopädie und kein Diskussionsboard für Teamviewer-Kritiker-DOS-vs.Brute-Force-ID-Echtheitszertifikats-Experten. Formulierungen wie "nach Herstellerangaben" o.ä. sind unterschwellig entwertend gegenüber der Glaubwürdigkeit desselben und gehören hier so nicht hinein, solange nicht das Gegenteil, also Mangel nicht bewiesen ist oeder ein besonders erhärtender Verdacht im Raume steht, der der allgemein interessierten Öffentlichkeit nicht länger verschwiegen werden darf. Man könnte das ganze Ding also mal bzgl. Unterschwelligkeiten entschärfen. Die ganze Diskussion erweckt hier eher den Eindruck (dafür ist kein Beweis nötig) dass sich hier ein Marktbegleiter oder Wichtigtuer etablieren möchte. Inwieweit man oder frau nun mutmaßt, dass der Schutz für D-O-S oder Brute Force Attacks vielleicht doch nicht so ganz perfekt ist wie vom Hersteller dargestellt, gehört ebenfalls hier nicht hin, jedenfalls solange die Attribute "mutmaßlich" und "vielleicht" vielleicht nicht vollständig ausgeräumt werden können. Das schreibt einer, der sich mit den gefallenen fachlichen Begriffen wenigstens ungefähr auskennt, seit ca. 4 Jahren TeamViewer professionell im IT-Service einsetzt (=kostenpflichtig lizensiert hat und auch von anspruchsvollsten/ sicherheitsbedürftigen Kunden akzeptiert/ anerkannt) und sich und andere trotz unverhohlener Sympathie/ Vertrauen für das eingesetzte Produkt resp. Hersteller gern so objektiv wie möglich informiert sehe. Zum Beispiel für meinen Kollegen siehe oben in Hamburg oder Entscheidungsträger oder Lieschen Müller, Meier, Schulze (Hauptzielgruppen einer Enzyklopädie) . Gruss aus Berlin J. Zielke chambionic ohg (nicht signierter Beitrag von 89.247.31.5 (Diskussion) 17:57, 6. Nov. 2010 (CET))

Versionen

Da der Kaufpreis nur für die jeweilige Version gilt kann jemand eine Tabelle einfügen in welchen Zeitzabständen Team Viewer die Hauptversion aktualisiert? Vielen Dank (nicht signierter Beitrag von 80.228.137.232 (Diskussion) 17:35, 29. Mai 2011 (CEST))

Verwendete Ports und NAT

Wie durchtunnelt TeamViewer NAT/Firewalls? Und welche Ports verwendet das Tool? --Jackobli 14:13, 6. Jun. 2011 (CEST)

Ich vermute, die Initialzündung erfolgt via Port 80, danach werden UDP-Ports geöffnet... --TobiToaster 14:40, 23. Aug. 2011 (CEST)

Für die private, nicht-kommerzielle Nutzung ohne Einschränkungen

"Für die private, nicht-kommerzielle Nutzung ist TeamViewer Freeware und kann ohne Einschränkungen genutzt werden" - So ganz stimmt das nicht. Ich habe einen Windows 2008 R2 Server. Und hier weigert es sich, als privat installiert zu werden. Ich bin ehrlich gesagt nicht bereit für die private Nutzung 500€ auszugeben. Zumal ich nur selten mal jemand so jemand inder Familie helfen muss. Ursdede16 (Diskussion) 18:17, 12. Mär. 2012 (CET)

Zu: "Erhebung von privaten Nutzerdaten"

Die hier zitierte Passage findet sich so nicht in der soeben herunter geladenen Version der Lizenz.txt (v7.0.12799). Ich finde zwei evtl. relevante Abschnitte: "6. ZUSTIMMUNG ZUR DATENVERWENDUNG. ... Nicht personenbezogene Daten können automatisch erfasst werden, um Ihnen einen erstklassigen Service zu bieten, insbesondere um die Bereitstellung von Software-Updates, Support, Inhalten, TPM und anderen Dienstleistungen für Sie zu erleichtern und zu verbessern." sowie "7. INHALTLICHE UPDATES; TECHNISCHE SCHUTZMASSNAHMEN (TPM). ... TeamViewer verfügt weltweit über Geschäftsstellen und wird hiermit von Ihnen ermächtigt, alle gesammelten Daten zu Verarbeitungszwecken an jede beliebige TeamViewer-Geschäftsstelle oder -Zweigniederlassung zu übermitteln, einschließlich Standorten außerhalb der USA oder der Europäischen Union. Ihre Zustimmung zu dieser Ziffer 7 beschränkt sich auf Daten, welche nicht personenbezogene Daten sind. Für jegliche erhobenen, verarbeiteten oder anderweitig verwendeten Daten in Zusammenhang mit dieser Ziffer 7 gilt Ziffer 6 entsprechend."

IANAL deshalb bitte ich um fachkundige Anpassung bzw. Überarbeitung. -- Begr3960 (Diskussion) 14:04, 26. Mär. 2012 (CEST)

Lemma

Aus FZW:

Soll TeamViewer entsprechend der Namenskonvention nach Teamviewer verschoben werden? --Boshomi (Diskussion) 20:27, 27. Jun. 2012 (CEST)

--Simon.hess (Disk, Bewerte mich!) 07:25, 28. Jun. 2012 (CEST)

Entsprechend der Namenskonvention könnte dann der Einleitungssatz wie folgt beginnen: »Teamviewer eigene Schreibweise TeamViewer...«--Boshomi (Diskussion) 08:08, 28. Jun. 2012 (CEST)
Einen einzelnen Buchstaben in einem nichtdeutschen Eigennamen finde ich nicht so schlimm, dass man das nicht lassen könnte. Solche Schreibweisen sind bei Software sehr üblich. --AndreasPraefcke (Diskussion) 10:54, 28. Jun. 2012 (CEST)

TeamViewer QuickSupport

Im entsprechenden Abschnitt steht: "TeamViewer QuickSupport ist nur für eingehende Verbindungen nutzbar, wobei Netzwerk- und VPN-Verbindungen nicht akzeptiert werden." Was soll das denn nun heissen? Wenn nicht aus dem Netzwerk, woher sonst soll denn eine eingehende Verbindung kommen? --Jackobli (Diskussion) 21:53, 6. Dez. 2012 (CET)

Mit Netzwerk ist aus dem LAN (lokales Netzwerk) gemeint, diese Verbindungen sind nicht möglich, sondern nur welche aus dem Internet.--Webka (Diskussion) 11:59, 28. Jan. 2013 (CET)

Ende-zu-Ende-Verschlüsselung

Teamviewer gibt an, durch Ende-zu-Ende-Verschlüsselung sei eine Analyse der Daten auf den Servern von Teamviewer absolut unmöglich. Hier im Artikel heißt es jedoch, es sei "sicherheitskritisch", dass Teamviewer sich über die Server von Teamviewer verbindet und dort könnten private Daten gesammelt werden.

Dieser Abschnitt sollte genauer erläutert werden. Wird den Angaben von Teamviewer nicht vertraut, weil sie mangels offenem Quellcode nicht geprüft werden können? Dann sollte das dort stehen. Oder geht es gar nicht darum, dass die übertragenen Daten (also die Bildschirminhalte, Tastatureingaben und übertragenen Dateien) gesammelt werden können, sondern lediglich darum, dass Teamviewer durch die über ihre Server initiierte Datenübertragung theoretisch speichern könnte, welcher Client sich mit welchen anderen Clients wie oft verbindet? Dann sollte das ebenfalls so gesagt werden.

In jedem Fall sollte auch erwähnt werden, dass die Verbindungen laut Teamviewer per Ende-zu-Ende-Verschlüsselung gesichert sind. --95.222.118.63 16:45, 27. Jan. 2013 (CET)

Habe den bisherigen, unklaren Abschnitt ersetzt durch einen, in dem die Aussagen durch die TeamViewer-Sicherheitsinformationen belegt sind. Wenn die Daten (in den meisten Fällen) nicht über die Server übertragen, sondern direkt zwischen den Teilnehmern ausgetauscht werden, kann der Datenstrom wohl zumindest dann auch nicht auf diesem Weg analysiert werden. Nach außen sind alle Verbindungen nach wie vor verschlüsselt. Ich habe auch den Eindruck, dass der bisherige Abschnitt von einer allzu theoretischen Gefahr ausgeht. Falls tatsächlich "welcher Client mit wem"-Informationen gemeint sind (und in der Speicherung solcher Daten ein Problem gesehen wird), wäre der richtige Ausdruck auch wohl eher "datenschutzkritisch". Falls Belege dafür gefunden werden, dass die Sicherheit der Verbindung durch die Benutzung der TeamViewer-Server gefährdet wird, sollten sie bitte eingefügt werden.

--Azovdealt (Diskussion) 01:58, 7. Jun. 2013 (CEST)

Baustein Neutralität

Bei diesem Artikel scheint es sich eher um einen Werbeprospektes als um einen enzyklopädischen Artikel zu handeln.

Dafür sprechen nach meiner Ansicht folgende Punkte:

  • Selbst marginale Produktbestandteile werden ausführlich beschrieben
  • Es wird der Eindruck erweckt, als ob die Teamviewer GmbH eine deutsche Firma ist, aber es geht aus dem Artikel nicht hervor, wie die deutsche TeamViewer GmbH mit der amerikanischen GFI Software zusammenhängt. Sollte eine solche Verbindung bestehen (wie auf der TeamViewer-Webseite angedeutet) wäre es für eine enzyklopädische Darstellung wichtig, da es im allgemeinen Interesse liegt, solche Details zu erwähnen. Aus geschäftlicher Sicht könnte es aber von Nachteil sein, wenn eine SW, die so tief im System arbeiten darf, dem US-Recht unterworfen wäre.
  • Bei früheren Versionen dieses Artikels wurde eingepflegt, dass TeamViewer auch nicht-personenbezogene Daten abgreift. Die ist möglich, da alle Daten über TeamViewer Server laufen. Die entsprechenden Erlaubnisse in den Lizenzbedingungen hat TeamViewer für die normalen Download-Versionen entfernt, aber über in der Portablen Anwendung sind sie noch da (siehe "5. DATA PROTECTION ... TeamViewer takes the protection of your personal data very seriously ... Non-personal or anonymous data may be collected automatically to improve functionality and your experience with our Product, in particular to facilitate and improve the provision of software updates, Support, Content, TPM and other services. You agree that any non-personal or anonymous data collected may be sent to any of our worldwide offices or affiliates for processing.") Das sollte wieder rein.

Ich denke, eine Kürzung des Artikels ist sinnvoll. Da aber bei jedem Update der Software der Artikel "liebevoll" gepflegt ist, sehe ich es als schwierig an, diese Pflege un Überwachung alleine zu übernehmen --WikiLangstrumpf (Diskussion) 21:42, 4. Apr. 2014 (CEST)


Man könnte ja auch ergänzen, dass die Software nicht in IPv6-Netzen (also ohne IPv4) lauffähig ist. Jedenfalls nicht in der aktuellen Version.

Das könnte man in dem Satz, wo die Wunder versprochen werden:

"durch Firewalls und NAT sowie Proxy-Server hindurch arbeitet." ergänzen, oder gar einen Abschnitt "Kritik" einfügen.

Ich habe nichts gegen Details in Wikipedia, nur stimmen sollten sie. Und negative Details sollten dann nicht verschwiegen werden. --Tschäfer (Diskussion) 12:43, 26. Aug. 2014 (CEST)

Geschäftsbeziehungen laut Bloomberg Businessweek

Für die Fa. TeamViewer GmbH gibt Bloomberg Businessweek (Stand October 05, 2014 7:24 AM ET) an:

Key Executives for TeamViewer GmbH:

Thilo Rosmanith 1 Relationships Founder and Director --

Kornelius Brunner No Relationships Head of Product Management --

Katrin Roessler No Relationships Head of Human Resources --

Holger Felgner 11 Relationships General Manager --


TeamViewer GmbH Board Members:

Thilo Rosmanith 1 Relationships TeamViewer GmbH

Alexander Crisses 18 Relationships Insight Venture Partners


Für Holger Felgner - General Manager TeamViewer GmbH findet man:

Mr. Holger Felgner has been General Manager of Teamviewer at GFI Software Florida Inc. and GFI Software Ltd. since October 2010. Mr. Felgner serves as General Manager at TeamViewer GmbH. He served as General Manager of Collaboration at GFI Software S.A. Mr. Felgner is responsible for GFI's Remote Access and Collaboration software, TeamViewer. Mr. Felgner served as the Chief Operating Officer of GFI. He worked at Rossmanith GmbH from 2002 to 2006, a company providing solutions for quality assurance and ISO 9001 certifications, holding various sales and development. He started his career in sales for Zeta Software GmbH. He has been a Director of GFI Software S.A. and GFI Software Ltd. since November 01, 2010. He has a Diploma in Industrial Engineering from Stuttgart Media University.

Für Crisses Alexander - Board Member Teamviewer GmbH findet man:

Mr. Alexander Crisses, Alex serves as a Managing Director at Insight Venture Partners. Mr. Crisses joined the Insight Venture Partners in 2002 and focuses on infrastructure software and internet investments. He is a key mentor of new team members at Insight and is part of the management team that oversees Insight's analyst recruiting and training program and assists with candidate selection and new employee on-boarding. Mr. Crisses served as an Investment Banking Analyst in the Global Energy and Power Group at Credit Suisse First Boston. He also invests in online gaming and “freemium“ software companies He was employed by Credit Suisse AG. Mr. Crisses also held prior experience in venture capital, investment management, and private banking. He is a former Fundraising Director for Minds Matter. He is an active supporter of the Make a Wish Foundation and The Jewish Foundation for the Righteous. Mr. Crisses serves as Director of GFI Software Ltd., TeamViewer GmbH, LOLapps, Six Waves Inc., Cvent, Wix, New Relic, 6Waves LOLapps, and Jagex Ltd. He has been a Director of Anaqua, Inc. since July 17, 2013. He served as Director of Ticket Monster Inc. Mr. Crisses holds an M.B.A. with High Distinction from the Harvard Business School, where he graduated as a George F. Baker Scholar. He also holds a B.S. in Economics with highest Honors from the University of Pennsylvania's Wharton School of Business and is the recipient of the Dean's Award for Excellence. (nicht signierter Beitrag von 93.131.94.97 (Diskussion) 13:43, 5. Okt. 2014 (CEST))

Kritik

Ein sehr kurzer Artikel für einen Verkaufswert von 1,1 Milliarden $ (!). Kritik sollte unbedingt in den Artikel Eingang finden. Meines Erachtens ist TeamViewer ein win-typischer Ressourcenfresser im Gegensatz zu z.B. putty oder auf Unixseite ssh. Von der Sicherheit des Konzepts bin ich auch nicht überzeugt, wenn auch nur aus Bauchgefühl, jedoch würde ich mir hier mehr Information erwarten. Lg, greybeard 22:06, 15. Okt. 2014 (CEST).

Was für ein Schwachsinn. FUD as its best. (nicht signierter Beitrag von 2003:6C:CC47:793B:D5E0:9A52:4A9D:7E0F (Diskussion | Beiträge) 20:25, 20. Nov. 2014 (CET))

Die oben stehende Kritik entbehrt jeder Sachkenntnis. TeamViewer ist von der Funktionsweise und den Anwendungsmöglichkeiten nicht mit PuTTY und SSH zu vergleichen. (nicht signierter Beitrag von 2.242.54.97 (Diskussion) 09:43, 6. Mai 2015 (CEST))

Stimmt; für den Ressourcenverbrauch braucht es schon etwas handfestere Einwände als den Vergleich mit nicht vergleichbaren Programmen. Wer Äpfel mit Birnen vergleicht, sollte keinen Neutralitätsbaustein setzen. Zur Sicherheit: Ein Man-in-the-middle-Angriff setzt direkten Zugang zu den Mechanismen voraus, die die Sicherheit kontrollieren. In diesem Fall ist das der "Hauptserver". Wer diesen administriert, hätte also rein theoretisch durchaus Missbrauchsmöglichkeiten und könnte an sensible Daten der Nutzer gelangen. Das ist insbesondere bei gesetzlichen Regelungen zu bedenken, die die Zusammenarbeit mit Geheimdiensten oder anderen ermittelnden Behörden betreffen. Mir ist allerdings nicht bekannt, wie die Rechtslage in Luxemburg und länderübergreifend innerhalb und außerhalb der EU ist. Es steht zu befürchten, dass amerikanische oder britische Geheimdienste durchaus Möglichkeiten finden, um möglicherweise Schwachstellen auszunutzen. Sollte es hier aber nicht einen wesentlich konkreteren Missbrauchsverdacht geben, halte ich den Neutralitätsbaustein für unbegründet. Ich werde den Artikel vorläufig knapp ergänzen und den Baustein entfernen. --H7 (Diskussion) 12:40, 5. Jul. 2015 (CEST)

Abkürzung

Üblicherweise wird TeamViewer mit TVr abgekürzt. Selten auch TV, da TV eigentlich eher für Television steht. Sollen wir das einfügen? --79.212.47.114 22:11, 9. Aug. 2015 (CEST)

Beleg? Diese Abkürzung ist mir noch nie begegnet, so viele Jahre ich diese Software auch schon einsetze.--Huberbe (Diskussion) 22:31, 9. Aug. 2015 (CEST)
Und selbst wenn: Nicht jede Abkürzung ist relevant. Was in Foren oder sozialen Netzwerken aus trivialer Schreibfaulheit üblich ist (wenn es denn so sein sollte), das hat wohl keine Relevanz. Wäre es eine Abkürzung, die allgmein so verwendet wird, auch z.B. mit redaktioneller Rezeption in relevanten Medien, hätte ich sie sicher irgendwo mal zur Kenntnis genommen. Das ist aber nicht der Fall. Deshalb auch von mir: Bitte Belege in zuverlässigen und etablierten Medien nennen, sonst bitte davon absehen. --H7 (Diskussion) 08:40, 10. Aug. 2015 (CEST)

Softwarehersteller

Ich sehe hier überhaupt keine Grundlage, die Kategorie:Softwarehersteller zu nennen. Die gleichnamige GmbH wird mit gerade mal einem Satz im ganzen Artikel thematisiert, alles andere beschreibt die Software. Damit wird der Hersteller nicht mal in nennenswertem Umfang mitbehandelt. Es handelt sich praktisch ausschließlich um einen Softwareartikel! --Ein fröhlicher Franke (Diskussion H7) 19:40, 7. Jan. 2018 (CET)

Ich halte es schon für angebracht, da ja wie du ja erkannt hast der Firmen Name dem Hauptprodukt gleich kommt.

Da es hier nur einen Artikel dazu gibt ist es schon sinnvoll. Oder du Legst einen sehr sehr kleinen Artikel für das Unternehmen an und Packst das da rein. Da nur sehr kleine Artikel mit nur wenig Inhalt nicht gerne gesehen werden, macht das hier schon Sinn. --Diamant001 (Diskussion) 17:49, 19. Jan. 2018 (CET)

Auslagerung des Unternehmens

Ich bin ja gerne bereit einzusehen, dass das Unternehmen eigenständig relevant ist. Aber muss man immer zwingend und unbedingt jedes Thema auslagern, nur weil es formal relevant ist? Der Unternehmensartikel hat momentan auf meinem (ganz normalen) Bildschirm etwa 7 1/2 Textzeilen, ohne Infobox wären es vielleicht nur 4-5 Textzeilen. Das hätte mal ganz bequem und ohne dass das Thema zu überbordend geworden wäre, im Hauptartikel belassen können. Das wäre halt einfach ein Abschnitt mit ein oder zwei Absätzen mehr als jetzt. Das wäre doch kein Problem gewesen, aber zusammengehöriges an einem Ort zu vereinen ist immer übersichtlicher als mehrere Miniartikel, die den Leser nötigen, mehrmals zu klicken und sich jedes mal die Infos aus dem vorherigen Artikel merken zu müssen. Manchmal (so auch hier) sind solche Auslagerungen ganz sicher keine Verbesserung für die Wikipedia. --H7 (Mid am Nämbercher redn!) 16:48, 15. Feb. 2019 (CET)

Vielleicht haben wir da einfach Ansichten, die ganz grundsätzlich unterschiedlich sind. Ich glaube im Gegenteil, dass ein Leser eher Wert darauf legt, einen zusammenhängenden Artikel vorgesetzt zu bekommen, der sich nur mit der Software befasst. Falls er dann tatsächlich Interesse am Unternehmen dahinter hat, wird es schon kein Problem für ihn sein, einem Wiki-Link zu folgen. Ich fände es eher störend, wenn ich unternehmensbezogene Daten (wie bspw. den Jahresumsatz, der ohne Frage relevant ist) aus dem Software-Artikel herausfiltern müsste. In diesem Falle ist die Software TeamViewer außerdem das Hauptprodukt, bei kleineren Unternehmen mit mehreren gleichrangigen Produkten dürfte es darüber hinaus schwer werden, sich auf ein Lemma festzulegen, unter welchem das Unternehmen selbst vorgestellt wird. PS: Auf meinem kleineren Laptop sind es schon ein paar Zeilen mehr.--Qwertz1894 (Diskussion) 17:03, 15. Feb. 2019 (CET)

Teamviewer Crippleware

Der Teamviewer 14 ist keine Freeware mehr. Als Nachweis habe ich ein Screencapture erstellt: YouTube 1gkI4_cT8uU (Link wg. Blacklist gesperrt - echt hart für Anfänger hier zu posten) Ich habe kein Interesse an einem Editwar oder Trolling und möchte die WikiRegeln gerne beachten. Einen Nachweis z.B. durch EULA Paragraphen zur sogenannten Freemium Version bei Teamviewer gibt es leider nicht. VG Boris --Xf01213 (Diskussion) 21:11, 2. Mär. 2019 (CET)

Danke für die Quelle - habe es übernommen. Grüße, --Schotterebene (Diskussion) 07:25, 3. Mär. 2019 (CET)
Man muss zwischen Geschäftsmodell und Lizenz unterscheiden; letzteres gehört gerne auch in die Einleitung. "Crippleware" ist ganz eindeutig pejorativ konnotiert und gehört deshalb ganz sicher nicht in die Einleitung. Die Lizenz ist für Privatnutzung Freeware (ist ja nicht dasselbe wie Freie Software). Im Übrigen habe ich hier noch was gefunden. Dass das als Crippleware wahrgenommen werden kann, wenn der Hersteller eine Fehlerkennung bewusst inkauf nimmt, ist schon klar, das ändert aber nichts an der Lizenz. Man könnte diesen Umstand evtl. noch in 2-3 Sätzen kurz darstellen (wenn man will, kann man ebenso gut auch bleiben lassen). --H7 (Mid am Nämbercher redn!) 16:38, 3. Mär. 2019 (CET)
Die Unterscheidung Geschäftsmodell und Lizenz kann ich nachvollziehen, warum gehört nur zweiteres in eine Einleitung? (Frage bitte für einen NeuEditor erklären). Ja, "Crippelware" ist eindeutig negativ wertend, wenn dies einen Sachverhalt wirklichkeitsgetreu wiedergibt ist das halt so. Die Wikipedia Definition von Crippleware erfüllt die zur Zeit vorliegende Version von Teamviewer zu 100%. Im Video wird bei 5:30min ein Hinweis auf die Lizenz gegeben, nicht auf ein Nutzungsverhalten. Von Verdacht auf Kommerzielle Nutzung ist in keiner der Meldungen die Rede. VG Boris--Xf01213 (Diskussion) 22:20, 3. Mär. 2019 (CET)
Das ist keine Neuerung von TeamViewer 14, das gab es schon vorher. Es kann aber sein, dass TeamViewer (das Unternehmen) langsam die Schrauben anzieht, damit Nutzer, die das Programm so (intensiv) nutzen als wäre es nicht privat, z.B. ein gewerblicher IT-Support, auch so behandelt werden, als wäre es ein nicht-privater Nutzer. Alternativ ist auch die Benutzung (deine Benutzung) ganz einfach einer nicht-privater Nutzung (wie immer man auch dies automatisiert feststellen will) ähnlicher geworden. -- WikiMax - 22:24, 3. Mär. 2019 (CET)
Ich kann dies bezüglich der Versionen nur sehr unregelmäßig nachvollziehen, weil ich die Software nur unregelmäßig nutze und auch nur spontan update. Was wäre dein Fazit: Freeware(Kostenlos / kostenlos für einen Personenkreis/Nutzung) oder Crippleware(Reduzierung der Funktion in wesentlichen Teilen um zum Kauf zu drängen)? VG Boris --Xf01213 (Diskussion) 22:37, 3. Mär. 2019 (CET)
Ich kann da diesbezüglich auch nur bedingt helfen. Ich selber nutze seit Jahren eine kostenpflichtige Software.
Die Nutzung von TeamViewer ist nicht für einen Personenkreis kostenpflichtig oder frei, sondern für die Art der Nutzung.
Es mag sein, dass mit Version 14 diesbezüglich Änderungen eingeführt wurden, aber vorher war es schon definitiv so, dass eine Nutzung, die "zufällig" tatsächlich keine private Nutzung war, eine Unterbrechung mit Meldung brachte, aber keinen eingeschränkten Funktionsumfang. Eine Pause macht meines Erachtens noch keine Crippleware. Die Zwangspause kommt auch glaube ich nicht automatisch bei jedem, nicht immer nach 5 Minuten, sondern nur unter bestimmten Umständen. -- WikiMax - 23:03, 3. Mär. 2019 (CET)

Meiner Meinung nach ist der Begriff "Crippleware" deutlich wertend, wie H7 bereits schrieb, und daher ein Verstoß gegen den NPOV. Ich würde eine neutralere Umschreibung bevorzugen. Youtube ist übrigens auch keine angemessene Quelle, gibt es keine Medienberichte? Minihaa (Diskussion) 18:32, 9. Mär. 2019 (CET)

Zudem ist die momentane Formulierung - so pauschal wie es jetzt klingt - schlicht nicht korrekt. Ich verwende auch die aktuelle Version für mehrere PCs in meinem privaten Umfeld (meine Eltern, dazu zwei Arbeitskollegen auf deren Privatrechner zuhause, insgesamt 5 Rechner, absolut heterogene Infrastruktur und verschiedene ISPs), ich habe diese Zwangspause noch nie erlebt. Es sind bestimmte Mechanismen, die in ihrer genauen Justierung nicht offen gelegt werden, die unter bestimmten Umständen eine (fälschliche) kommerzielle Verwendung vermuten und deren Einschränkung anscheinend per Online-Formular auch administrativ abgeschaltet wird. Crippleware heißt doch, dass eine störende Einschränkung vorliegt. Das ist so pauschal wie im Artikel dargestellt, nicht der Fall. --H7 (Mid am Nämbercher redn!) 19:19, 9. Mär. 2019 (CET)

Lizenz Host - Gast

früher war es egal, ob der Host oder Gast die Lizenz hatte. Seit einiger Zeit muss wohl zwingend der Gast die Lizenz haben. Ab wann das geändert wurde, sollte auch im Artikel stehen. --2001:16B8:22F4:2D00:B1E9:3BFB:4B92:FA39 10:02, 22. Jul. 2020 (CEST)

Aktueller Spiegel-Artikel (17. Mai 2019) zu Hack

https://www.spiegel.de/plus/teamviewer-wie-hacker-das-deutsche-vorzeige-start-up-ausspionierten-a-00000000-0002-0001-0000-000163955857

Dieser Artikel ist nicht frei lesbar! Der Artikel ist aber bei zdnet verlinkt.
Ein Artikel von heise aus 2016 könnte hingegen vielleicht noch referenziert werden?
https://www.heise.de/newsticker/meldung/TeamViewer-war-2016-Opfer-eines-Cyber-Angriffs-4425265.html
--213.196.222.82 15:01, 12. Jan. 2021 (CET)

Letzte Änderungen

TeamViewer hat sich in letzter Zeit stark verändert. Die Funktionalität wurde insbesondere im Bereich der Zusammenarbeit (Audio-/Videokonferenzen etc.) ergänzt. Das Betriebssysteme Chrome OS wird über Android unterstützt, eine Nennung in der Infobox erscheint uns daher nicht mehr direkt angebracht. Wir haben versucht, alle ausstehenden Aktualisierungen einzutragen und den Eintrag daher überarbeitet. Ein kritischer Blick der Community wäre toll. -- TeamViewer Kommunikation (Diskussion) 16:05, 5. Feb. 2021 (CET)

Alternativen

Welche Alternativen gibt es? (nicht signierter Beitrag von 87.185.43.132 (Diskussion) 08:04, 9. Mai 2021 (CEST))

Klicke unten auf Kategorie:Fernwartungssoftware M@rcela Miniauge2.gif 10:37, 9. Mai 2021 (CEST)