Web Features That May Not Work As You’d Expect

Während das Web immer leistungsfähiger wird, können Entwickler reichhaltigere Online-Erlebnisse schaffen. Es gibt jedoch Zeiten, in denen einige neue Web-Funktionen im Interesse der Benutzerfreundlichkeit, Sicherheit und Privatsphäre möglicherweise nicht wie erwartet funktionieren.

Ich bin schon auf solche Situationen gestoßen. Wie Lazy Loading in HTML. Es ist einfach, dieses Attribut zu einem Bildelement hinzuzufügen, nur um festzustellen, dass... es eigentlich mehr als das braucht, um zu funktionieren. Wir werden uns gleich damit beschäftigen, wenn wir uns ein paar andere Funktionen ansehen, die vielleicht nicht *genau* wie erwartet funktionieren.

:visited Links haben eingeschränkte Styling-Optionen und getComputedStyle lügt über ihren Stil

Diese Einschränkung besteht schon seit einiger Zeit, zeigt aber, wie Browserfunktionen ausgenutzt werden können. Ein möglicher Exploit ist, dass ein Link einen :visited-Link-Stil in CSS erhält und außerhalb des Bildschirms positioniert wird. Mit dem Link außerhalb des Bildschirms könnte man mit JavaScript den href-Wert des Links ändern und sehen, ob ein bestimmter href dazu führt, dass der Link als besucht erscheint – und dabei die Historie eines Benutzers rekonstruiert.

Bekannt als CSS History Leak, war dies zu einer Zeit so verbreitet, dass die Federal Trade Commission, die Verbraucherschutzbehörde der Vereinigten Staaten, harte Strafen für die Ausnutzung verhängt hatte.

Heutzutage gibt die Verwendung von getComputedStyle auf einem :visited-Link den Stil des unbesuchten (:link) Links zurück. Das ist nur eine dieser Dinge, die man wissen muss, weil es anders ist, als es intuitiv funktionieren sollte.

Es gibt zwei Ansätze, wie man versuchen könnte, dies zu umgehen, aber keiner davon ist möglich.

1. den Stil des besuchten Links einen Nebeneffekt auslösen lassen (z. B. eine Layoutverschiebung) oder
2. Geschwister- (~ oder +) oder Kind-Selektoren (>) nutzen, um einen anderen Stil zu rendern.

Was Nebeneffekte angeht, gibt es zwar einige clevere, aber fragile Wege, dies zu tun, aber die Optionen, die wir zum Styling von :visited-Links haben, sind begrenzt und einige Stile (wie background-color) funktionieren nur, wenn sie auf unbesuchte Links angewendet werden. Was die Verwendung von Geschwistern oder Kindern angeht, gibt die Ausführung von getComputedStyle auf diesen den Stil zurück, als ob der Link von Anfang an nicht besucht worden wäre.

Browser cachen Assets nicht mehr seitenübergreifend

Ein Vorteil von CDNs war, dass sie es ermöglichten, eine bestimmte Ressource (wie Google Fonts) im Browser zu cachen, um sie auf verschiedenen Websites zu verwenden. Dies bringt zwar einen großen Leistungsgewinn, hat aber gravierende Auswirkungen auf die Privatsphäre.

Da ein bereits gecachter Asset länger zum Laden benötigt als ein nicht gecachter, könnte eine Website einen Timing-Angriff durchführen, um nicht nur Ihre Website-Historie zu sehen, sondern auch preiszugeben, wer Sie sind und was Sie online tun. Jeff Kaufman gibt ein Beispiel

Leider ermöglicht ein gemeinsamer Cache ein Ausspähen der Privatsphäre. Zusammenfassung der einfachsten Version

• Ich möchte wissen, ob Sie Moderator auf www.forum.example sind.
• Ich weiß, dass nur Seiten unterladen www.forum.example/moderators/header.css.
• Wenn Sie meine Seite besuchen, lade ich www.forum.example/moderators/header.css und sehe, ob sie aus dem Cache kam.

Daher bieten Browser dies nicht mehr an.

performance.now() kann ungenau sein

Vor ein paar Jahren kam eine beängstigende Gruppe von Schwachstellen heraus, von denen eine Spectre hieß. Für eine eingehende Erklärung siehe Googles leaky.page (funktioniert am besten in Chromium) als Proof of Concept. Aber für die Zwecke dieses Artikels reicht es zu wissen, dass der Exploit darauf angewiesen ist, hochpräzise Zeitmessungen zu erhalten, was performance.now() bietet, um sensible CPU-Daten abzubilden.

Um Spectre zu mildern, haben Browser seine Genauigkeit reduziert und fügen möglicherweise Rauschen hinzu. Diese reichen von 20 μs bis 1 ms und können je nach verschiedenen Bedingungen wie HTTP-Headern und Browsereinstellungen geändert werden.

Lazy Loading mit dem loading-Attribut funktioniert nicht ohne JavaScript

Lazy Loading ist eine Technik, bei der Assets erst im Browser geladen werden, wenn sie in den Viewport scrollen. Bis vor kurzem konnten wir dies nur mit JavaScript über IntersectionObserver oder onscroll implementieren. Mit Ausnahme von Safari können wir das loading-Attribut auf Bilder und iframes (in Chromium) anwenden, und der Browser übernimmt das Lazy Loading.

Beachten Sie, dass Lazy Loading nicht mit Polyfills nachgebildet werden kann, da ein Bild wahrscheinlich geladen wird, bevor Sie die Unterstützung für das loading-Attribut prüfen.

Die Möglichkeit, dies in HTML zu tun, lässt das Attribut so klingen, als ob es überhaupt kein JavaScript benötigt, aber das tut es. Aus der WHATWG-Spezifikation

1. Wenn Scripting für ein Element deaktiviert ist, geben Sie false zurück.

   Hinweis
   Dies ist eine Anti-Tracking-Maßnahme, denn wenn ein User-Agent Lazy Loading bei deaktiviertem Scripting unterstützen würde, wäre es für eine Website immer noch möglich, die ungefähre Scroll-Position eines Benutzers während einer Sitzung zu verfolgen, indem Bilder im Markup einer Seite strategisch platziert werden, sodass ein Server verfolgen kann, wie viele Bilder angefordert und wann sie angefordert werden.

Ich habe Artikel gesehen, die erwähnen, dass dieses Attribut die Unterstützung für Lazy Loading „ohne JavaScript“ ermöglicht, was nicht stimmt, obwohl es stimmt, dass Sie keines schreiben müssen.

Browser können Funktionen basierend auf Benutzereinstellungen einschränken

Einige Benutzer möchten möglicherweise die Browserfunktionalität im Interesse weiterer Sicherheit und Privatsphäre stark einschränken. Firefox und Tor sind zwei Browser, die dies über die Einstellung Resist Fingerprinting tun, die Dinge wie die Reduzierung der Genauigkeit bestimmter Variablen (Dimensionen und Zeit), das Weglassen bestimmter Variablen, die Einschränkung oder Deaktivierung einiger Web-APIs und das niemals Übereinstimmen von Media Queries umfasst. WebKit hat ein Dokument, das beschreibt, wie Browser Fingerprinting-Resistenz angehen können.

Beachten Sie, dass dies über die standardmäßigen Anti-Tracking-Funktionen hinausgeht, die Browser implementieren. Es ist unwahrscheinlich, dass ein Benutzer dies aktiviert, da er ein sehr spezifisches Bedrohungsmodell dafür benötigen würde. Ein Teil davon kann durch progressive Verbesserung, anmutige Degradation und das Verständnis Ihrer Benutzer ausgeglichen werden. Diese Einschränkung ist ein großes Problem, wenn Sie tatsächlich Fingerprinting benötigen, wie z. B. bei der Betrugserkennung. Wenn es also absolut notwendig ist, suchen Sie nach alternativen Mitteln.

Screenreader geben die Semantik bestimmter Elemente möglicherweise nicht weiter

Semantisches HTML ist aus vielen Gründen großartig, vor allem, weil es Bedeutung in Markup vermittelt, das Software wie Screenreader interpretiert und Benutzern ankündigt, die darauf angewiesen sind, das Web zu navigieren. Es ist unerlässlich für die Erstellung zugänglicher Websites. Aber manchmal werden diese Semantiken nicht weitergegeben – zumindest nicht so, wie Sie es vielleicht erwarten. Etwas kann zugänglich sein, aber immer noch Benutzerfreundlichkeitsprobleme aufweisen.

Ein Beispiel dafür ist, wie das Entfernen der Markierungen einer Liste ihre semantische Bedeutung aufhebt in WebKit mit aktiviertem VoiceOver. Es ist ein sehr gängiges Muster, insbesondere für die Website-Navigation. Der Apple Accessibility Standards Manager James Craig erklärt, warum es ein Benutzerfreundlichkeitsproblem darstellt, und verweist auf das W3C Design Principle of Priority of Constituencies

Im Falle eines Konflikts sind Benutzer wichtiger als Autoren, Implementierer, Spezifizierer oder theoretische Reinheit. Mit anderen Worten: **Kosten oder Schwierigkeiten für den Benutzer sollten mehr Gewicht haben als Kosten für Autoren**;

Ein weiterer Fall, in dem Semantiken möglicherweise nicht weitergegeben werden, ist die Betonung. Nehmen Sie Inline-Elemente wie strong, em, mark, ins, del und data – alles Elemente, die semantische Bedeutungen haben, aber wahrscheinlich nicht vorgelesen werden, da sie laut sein können. Dies kann in den Einstellungen des Screenreaders eines Benutzers geändert werden, aber wenn Sie wirklich möchten, dass es gelesen wird, können Sie es in visuell verstecktem Text in der content-Eigenschaft eines :before oder :after Pseudoelements deklarieren.

Um dies zu veranschaulichen, habe ich ein kurzes Beispiel erstellt, um zu sehen, wie NVDA mit Firefox 89 und VoiceOver mit Safari 14.6 semantische Elemente vorlesen.

Im Gegensatz zu VoiceOver liest NVDA einige der semantischen Elemente (del, ins und mark) vor und versucht, Text zu betonen, indem es die Lautstärke des betonten Textes allmählich erhöht. Beide haben jedoch keine Probleme beim Lesen der :before/:after Pseudoelemente. Außerdem liest VoiceOver die Klammern des Tags (größer als, kleiner als) vor, obwohl beide Screenreader die Möglichkeit haben, zu ändern, wie viel Satzzeichen gelesen wird.

Um zu sehen, ob Sie die Hervorhebung betonen müssen oder nicht, stellen Sie sicher, dass Sie mit Ihren Benutzern testen und sehen, was sie brauchen. Ich habe mich nicht auf den visuellen Aspekt konzentriert, aber das Standard-Styling von Hervorhebungselementen kann zwischen den Browsern inkonsistent sein. Stellen Sie daher sicher, dass Sie geeignete Stilmittel mitliefern.

Webspeicher ist möglicherweise nicht persistent

Die WHATWG Webspeicher-Spezifikation enthält einen Abschnitt über Datenschutz, der mögliche Wege aufzeigt, um zu verhindern, dass Speicher zu einem Tracking-Vektor wird. Eine dieser Methoden ist, die Daten ablaufen zu lassen. Deshalb begrenzt Safari kontrovers die Skript-beschreibbaren Speicher auf sieben Tage. Beachten Sie, dass dies nicht für „installierte“ Websites gilt, die zum Startbildschirm hinzugefügt wurden.

Fazit

Interessant, nicht wahr? Einige Web-Funktionen, von denen wir erwarten, dass sie auf eine bestimmte Weise funktionieren, tun es einfach nicht. Das soll nicht heißen, dass die Funktionen falsch sind und behoben werden müssen, sondern eher ein Hinweis, wenn wir Code schreiben.

Es lohnt sich, Ihre eigenen Annahmen während der Entwicklung zu hinterfragen. Untersuchen Sie kritisch, was Ihre Benutzer benötigen, und berücksichtigen Sie dies bei der Erstellung Ihrer Website. Sie können diese gerne umgehen, wenn Sie auf sie stoßen, aber in Fällen, in denen Sie dazu nicht in der Lage sind, stellen Sie sicher, dass Sie eine angemessene progressive Verbesserung und anmutige Verschlechterung finden und bereitstellen. Es ist in Ordnung, wenn Benutzer eine Website nicht in jedem Browser genau gleich erleben, solange sie das tun können, was sie tun müssen.

Das ist meine Liste der Dinge, die nicht so funktionieren, wie ich es erwarte. Was steht auf Ihrer Liste? Ich bin sicher, Sie haben einige und würde sie gerne in den Kommentaren sehen!