iFrame: strict-origin-when-cross-origin

Sagt mal, gibt es irgendeinen Weg, das strict-origin-when-cross-origin bei iFrames zu umgehen, also dauerhaft, ohne dass der User, der das einbindet, was ändern kann?

Bisher war der Default-Wert der Referrer-Policy ja immer "no-referrer-when-downgrade". Er wurde also vollständig gesendet, wenn das Ziel das gleiche Schema (beide SSL oder beide nicht oder eben das Ziel ein besserer hatte) hatte. Das war unabhängig ob es der gleiche Host ist oder nicht.

Das wurde nun geändert, erst bei Chrome, dann bei Edge und nun bei Firefox. Neuer Default-Wert ist nun "strict-origin-when-cross-origin" und der sendet nur noch vollständig, wenn es der gleiche Host ist. Bei cross-Origin kommt nur noch als Referrer der "Origin", aber kein Path mehr.

Für mich mit meinen 50.000 externen Kalendern ganz schlecht, denn ich kann quasi keinen mehr erfassen, denn es kommt ja nur noch der Host als Referrer zurück und nicht mehr die eigentliche Seite.

Teilweise richtig verstanden. Die Kalender werden per iFrame irgendwo eingebunden. Alles was ich möchte ist zu wissen wo, damit mein System dann prüfen kann, ob das so auch passt und den Bedingungen entspricht. Der Kalender selbst tut nichts, das ist nur eine Ansicht.

Bisher kein Problem, sobald der angezeigt wird kommt der Referrer http://domain.de/seite-x und zack, ich hab ihn. Nun kommt halt nur noch domain.de/. Und da läuft das System dann hohl, weil es den Kalender eben auf domain.de/ sucht und nicht findet. Klar, die Pfad-Angabe fehlt ja.

Dein Link da ist genau das Problem, denn seit der Änderung fehlt eben der Pfad. Firefox änderte das so ca. vor 6 Wochen. Ich kann zwar dem iFame selbst ein referrerpolicy="no-referrer-when-downgrade" mitgeben (vorheriger Default-Wert), aber das bringt nicht viel, denn das kann ja jeder Nutzer einfach entfernen oder ändern. Und viele nutzen auch Joomla, Typo3 oder sonst was und deren Wrapper, also sind da meine Vorgaben eh futsch.

Das mit dem Script habe ich mir auch schon überlegt, schon vorher. Hat einen Nachteil und nun eigentlich zwei.

1. Nicht alle können Scripte einbinden. Ich bin schon froh, dass die meisten dieser Baukästen inzwischen IFrame können

getestet habe ich das aber dennoch, vor meinem Thread hier als extra Script, das eben senden soll, wo es aufgerufen wurde. Ausgeliefert im IFrame.

2. Problem: Das geht auch nicht, denn das Script (AJAX) unterliegt auch dem "strict-origin-when-cross-origin", denn er ruft ja Daten von extern ab.

Mein Versuch war daher eher in die andere Richtung. Extra Script, dessen Referrer mir völlig egal ist, das dann die URI schnappt, verschlüsselt und zurückschickt. Das könnte theoretisch gehen, wäre aber ein gänzlich anderer Programmablauf als jetzt und es müssten alle 50.000 Kalender geändert werden, also nicht die Kalender, sondern die Codes für IFrame + Script. Und eben auch das Problem, dass viele das dann gar nicht eingebunden bekommen, also IFrame und Script.

Und der Programmablauf wie gesagt auch völlig anders. Aktuell ist es ja so, dass da eine Anfrage an meine Kalender.php reinkommt. Die schaut nach, wann der Kalender das letzte mal geprüft wurde. Ist es älter als 7 Tage, dann wird erst erneut geprüft (URL vom Referrer), dann ausgeliefert, wenn alles ok ist. Mit einem extra Script müsste das ausgelagert werden, eine Art Liste, die dann abgearbeitet werden muss, denn einen direkten Zusammenhang zwischen Kalender ausliefern und testen gibt es dann ja nicht mehr.

Irgendwie ist das alles doof. Die mit ihrem Datenschutzwahnsinn immer.

mist