Gemäss den Empfehlungen im Artikel Hardening Google Chrome habe ich die Sync-Einstellungen meines Desktop-Browsers folgendermassen eingeschränkt:
Und auf iOS-Geräten sehen meine Einstellungen so aus:
Dienstag, 8. August 2017
Gemäss den Empfehlungen im Artikel Hardening Google Chrome habe ich die Sync-Einstellungen meines Desktop-Browsers folgendermassen eingeschränkt:
Und auf iOS-Geräten sehen meine Einstellungen so aus:
Tags: Einstellungen, Google, Google Chrome, Hardening, Härtung, Settings, Sync, Sync Settings
Labels: IT
Dienstag, 8. August 2017
Als Security Officer befasst man sich gelegentlich auch mit TLS-Zertifikaten von Web-Sites. Wenn man die Zertifikate und die Verschlüsselung einer im öffentlichen Internet ansprechbaren Web-Site bewerten lassen möchte, verwendet man dazu am Besten Qualys SSL Server Test.
Manchmal aber sind Web-Applikationen nur im Intranet erreichbar, oder manchmal möchte man einfach nur ganz rasch in Erfahrung bringen, welche Verschlüsselung eine Web-Site einsetzt.
Bis vor kurzem ging das in Chrome ganz flott: In der URL-Bar klickte man auf das Schloss-Symbol und erhielt mit ein, zwei Klicks alle nötigen Informationen präsentiert. Spätestens seit Version 59 klappt das nicht mehr.
In Version 60 haben die Chrome-Entwickler das Problem resp. den Kundenwunsch erkannt und ermöglichen es neu, die Funktionalität mittels einer Konfigurationseinstellung wieder zu reaktivieren:
Via: Configure Google Chrome to display certificates directly
Und ab sofort gibt es mit Klick auf das Schlosssymbol einer Web-Site wieder den Eintrag „Certificate“:
Mit Klick auf Valid öffnet sich danach ein os-spezifisches Fenster mit Informationen zum Zertifikat:
Tags: Chrome, Details, Flags, Google, Google Chrome, SSL, TLS, Zertifikat
Labels: IT
Sonntag, 5. Februar 2017
imapfilter funktioniert bei mir wunderbar, um in meiner INBOX eintreffende Mails automatisiert in Unterordner zu verschieben.
Dann und wann bricht das per Cron aufgerufene Script seine Arbeit aber ab, weil das Zertifikat des Mail-Servers gewechselt wurde:
imapfilter: certificate mismatch in non-interactive mode
imapfilter muss in einem solchen Fall interaktiv gestartet und das neue Zertifikat permanent akzeptiert werden.
Wen dieses Verhalten stört und die eindeutige Identifikation seiner Gegenseite weniger wichtig ist als ein sauber durchlaufendes Script, fügt oben an seine imapfilter-Regeln folgende Zeile ein:
... options.certificates = false ...
Quelle: Ignore certificate fingerprint mismatch
Ich habe das bei mir nur für ein kaum genutztes Gmail-Konto aktiviert.
Das Problem könnte mit den hier geschilderten zwei gleichzeitig aktiven, unterschiedlichen Gmail-Zertifikaten zusammenhängen.
Tags: Fingerprint, Gmail, Google, imapfilter, mismatch, Zertifikat
Labels: Linux
Mittwoch, 21. September 2016
Das geht ganz einfach: Auf der Web-Oberfläche klickt man auf den Pfeil-Button, um ein Dropdown mit den Eigenschaften des Kalenders anzuzeigen:
Dort klickt man auf „Papierkorb ansehen“ und erhält eine Liste der in den letzten 30 Tagen gelöschten Einträge:
Einzelne Einträge kann man mit Klick auf die Checkbox links und dem Button „Ausgewählte Termine wiederherstellen“ am Ende der Liste wiederherstellen.
Tags: Google, Google Calendar, Google Kalender, How-To, löschen, undelete, wiederherstellen
Labels: IT
Freitag, 12. August 2016
In solchen Fällen lohnt es sich, mit dem Browser als erstes folgende URL aufzurufen:
calendar.google.com/calendar/iphoneselect
Dort überprüft man, ob man den gewünschten Kalender tatsächlich zur Synchronisation mit iOS-Geräten (iPhone oder iPad) ausgewählt hat.
Quelle: HOW TO SYNC MULTIPLE GOOGLE CALENDARS TO YOUR IPHONE OR IPAD
Tags: Google, Google Calendar, iOS, iPad, iPhone, Kalender, Sync, Synchronisation
Labels: Apple
Sonntag, 22. Mai 2016
In der Branche ein offenes Geheimnis:
Derzeit greift Apple auf einen Mix von Amazon, Microsoft Azure sowie Googles Cloud zurück, um seine Internet-Dienste zur Verfügung zu stellen. Obiger Screenshot einer Meldung der Firewall Little Snitch belegt dies.
Tags: Amazon, Cloud, Google, iCloud, Microsoft
Labels: Apple
Donnerstag, 30. April 2015
Um den Google Updater unter OS X effektiv und permanent abzuwürgen, empfiehlt sich folgendes Vorgehen:
$ cd ~/Library/LaunchAgents $ chmod 0 com.google.keystone.agent.plist
Quelle: MacBook Pro keeps freezing, could Google Update be the cause?
Tags: Google, Google Updater, LaunchAgents, Library, OS X
Labels: Apple
Montag, 15. Dezember 2014
Heute morgen wurde ich von einem Angehörigen zu einem Supportfall gerufen: Er könne sich auf der Arbeit nicht mehr in sein Google-Konto einloggen, weil er die SMS mit den Zwei-Faktor-Codes aus unbekannten Gründen nicht mehr auf das Telefon zugesendet erhielt.
Googles Zwei-Faktor-Authentifizierung hatte ich ihm vor einigen Wochen eingeschaltet, nachdem gerade wieder Horror-Stories mit gekaperten Gmail- und Apple-Konten die Runden machten.
Es folgte ein halbstündiger Versuch von Fernsupport per iMessage, der mich fast zur Verzweiflung brachte: Als erstes erörtete ich die Möglichkeiten, dem Hilferufenden den SMS-Code über einen anderen Weg zu übermitteln — ein automatisierter Telefonanruf anstelle des SMS-Codes scheint für Schweizer Mobilfunknummern nicht angeboten zu werden. Die Option, 3 bis 5 Arbeitstage auf eine Rücksetzung des Kontos zu warten schlug ich ebenfalls aus.
Ich wendete mich deshalb dem Mobiltelefon zu: Wieso zum Teufel erhielt es die SMS nicht zugestellt? Die SIM-Karte stammt von Coop Mobile mit Prix Garantie, d.h. der Pre-Paid-Option. Coop Mobile ist ein MVNO, welcher über das Mobilfunknetz von Orange operiert. Ich weiss von bei mir eingerichteten Kalender-Alarmen, dass Google SMS aus dem Vereinigten Königreich versendet. Könnte es sein, dass Google die SMS derart krude oder illegal versendet, dass sie von Coop Mobile geblockt werden?
Google-Recherchen förderten ein älteres Problem mit einem rumänischen Mobilfunkanbieter zu Tage, bezüglich Coop Mobile/Orange fand ich aber keinen einzigen Beitrag.
Oder war die SMSC (SMS-Center-Konfiguration) des Handys etwa am Arsch?
Als erstes googelte ich nach Möglichkeiten, die SMSC-Konfiguration des iPhones anzuzeigen. Ich stiess dabei auf den Knowledgebase-Artikel Change or add the SMSC number to apple iPhone, welcher dem interessierten Frickler folgenden Code anbot:
*#5005*7672#
Ich probierte den Code auf meinem Gerät aus, erstellte Screenshots und versendete diese per iMessage an den Hilfesuchenden. Ich forderte meinen Angehörigen auf, diese Nummer einzugeben und anrufen. Als Antwort erschien auf dessen Display:
Abfrage der Einstellung fehlgeschlagen. Für Dienstcenter
Er fragte mich daraufhin, ob „mobile netz“ eingeschalten sein müsste. Ich klarifizierte, dass Mobile Daten für den Empfang und Versand von SMS nicht benötigt würden. Doch diese Frage regte meine Gehirnwindungen an: „Wird oben links eigentlich Orange CH angezeigt?“ — „Nein, nur VPN“ — „Ja, schon klar, du bist auf der Arbeit, aber … links davon, steht da Orange CH?“ — „Nein, dort steht SIM gesperrt“.
Ich nahm deshalb mein iPhone zur Hand und rief auf dessen Nummer an. Und tatsächlich erhielt ich die Meldung: „Der Teilnehmer ist momentan nicht erreichbar“. Voilà, kein Wunder kommen keine SMS an!
Wie sich herausstellte hatte die Person letzte Woche iOS 8.1.2 auf seinem Gerät installiert. Nach dem Neustart des iPhones wurde er zwar aufgefordert, die SIM-Karte zu entsperren, da er den Code aber nicht zur Hand hatte, vernachlässigte er die Meldung. Da er offenbar selten Telefonanrufe und SMS-Nachrichten erhält und im heimischen Netzwerk und im WLAN auf der Arbeit iMessage und alle anderen Internetdienste funktionierten, wurde die Person nicht misstrauisch.
Diese Anekdote ist wieder einmal eine Mahnung an uns Generation Internet und Smartphone: Die mobilen Technologien bringen eine ungeheure Komplexität mit sich, welche die älteren Benutzer weiterhin stark überfordert. Wenn das nur gut ausgeht …
Tags: 2-Step-Verification, 2FA, Coop Mobile, Google, PIN, SIM, SMS, SMSC, Zwei-Faktor-Authentifizierung
Labels: Leben
Mittwoch, 18. Dezember 2013
Seit Monaten plagten mich die Log-Dateien eines von mir betreuten Web-Projektes: Bestimmte URLs wurden von Googlebot periodisch wiederkehrend aufgerufen, obwohl die Informationen dieser Web-Seiten vor langer Zeit deaktiviert worden waren (kurz: Die Objekte wie Personen und Referate waren nicht mehr in der Datenbank vorhanden und generierten beim Aufruf eine PHP-Exception, welche zwar abgefangen wurde, aber meine Log-Dateien vollmüllte) und das Script seit einigen Wochen einen HTTP 404-Fehler zurückgab.
Wie zum Teufel kam der Googlebot immer wieder auf diese verflixten URLs zurück?
Ich hatte eine verdächtige Subdomain des Projektes im Visier, welche eine archivierte Version der Web-Site bereitstellte. Deshalb passte ich die URLs auf dieser Web-Seite dort an und fügte ihnen eine GET-Variable hinzu, welche unmissverständlich aufzeigen sollte, ob der Googlebot die URLs von dieser Web-Site bezog. Leider stellte sich heraus, dass die Ursache des Übels nicht von dieser Web-Site herrührte.
Daraufhin wählte ich URLs aus, welche eine ganz bestimmte, möglichst einmalige Zeichenkette enthielten und gab diese in der Google-Suche ein. Tatsächlich lieferte Google die Seite der Web-Site als Resultat aus — obwohl die Seite seit Wochen HTTP 404 retournierte. Ein Blick auf den Zeitpunkt des Caches bestätigte, dass Google eine mehrere Wochen alte Version aufbewahrte, welche kurz vor dem Einbau der 404-Routine gecrawlt wurde.
Nun gut, sagte ich mir: Irgendwann einmal muss ja der Googlebot akzeptieren, dass eine URL permanent einen 404er zurückliefert und diese URL dann nicht mehr regelmässig anpingen. Falsch gedacht:
Once Googlebot finds and crawls a URL, they will periodically come back and crawl it again forever. Even after you remove the page and have been returning 404 status for years, Googlebot will still crawl the URL from time to time.
Quelle: Google Crawls my disabled products on my Magento website [closed]
So ist das. Gibt es also wirklich nichts, was ein besorgter Webmaster tun kann? Doch, durchaus:
I followed up on the 404 vs 410 thing with the team here. As mentioned by some others here & elsewhere, we have generally been treating them the same in the past.
However, after looking at how webmasters use them in practice we are now treating the 410 HTTP result code as a bit „more permanent“ than a 404. So if you’re absolutely sure that a page no longer exists and will never exist again, using a 410 would likely be a good thing. I don’t think it’s worth rewriting a server to change from 404 to 410, but if you’re looking at that part of your code anyway, you might as well choose the „permanent“ result code if you can be absolutely sure that the URL will not be used again. If you can’t be sure of that (for whatever reason), then I would recommend sticking to the 404 HTTP result code.
In the worst case, the 410 will be treated the same as a 404; in the best case it’ll be a bit quicker & stickier :-).
Quelle: Does it make sense to return a 410 instead of 404 when some page has been permanently removed?, Via: Does it make sense to return a 410 instead of 404 when some page has been permanently removed?
Ich passte also meinen try-catch-Block im Script an, welcher neu heisst:
... header("HTTP/1.0 410 Gone"); ...
Tags: 404, 410, Crawler, Google, HTTP, robots.txt
Labels: Programmierung