Window.name как транспорт данных: действительный подход?

Обзор и оригинальный вопрос

window.name - интересный зверь. Описание MDN подсказывает исходное намерение:

Имя окна используется в основном для установки целей для гиперссылок и форм. Windows не нужно иметь имена.

Итак, это означает, что мы можем открыть консоль в этом окне и написать:

var win = window.open('http://google.com', 'el goog');

... а затем пропустите его через блокировщик всплывающих окон, который должен открыть google.com в окне с именем "el goog". Я не могу получить доступ к свойству name win из-за политики одного и того же происхождения, но если я открою консоль в новом окне и наберу name, я получу "el goog".

Если я отправлю окно обратно в домен, из которого я его открыл (в данном случае stackoverflow.com), я могу получить свойство name, и он не изменился.

win.location.replace(location.href);
win.name; // "el goog"

Это означает, что у нас может быть своего рода хранилище сеансов междоменного сеанса, установив свойство name окна.

Если google.com изменил значение window.name до того, как окно было отправлено обратно в исходный домен, мы увидим новое значение вместо "el goog". Это можно использовать в качестве междоменной передачи данных, аналогичной утилите для JSONP или CORS.

Я немного искал, пытаясь найти больше информации, и, по-видимому, dojo считает это законным в качестве транспорта. Так или иначе, это не совсем успокаивает меня. Итак, мой вопрос в том, являются ли какие-либо уважаемые сайты, использующие window.name в качестве транспорта данных? Я бы подумал, что это будет легко замечено, потому что их документы скажут что-то вроде "добавить" обратный вызов "в строку запроса для JSONP или добавить" что угодно "для window.name", но я никогда не видел ничего подобного. Кто-нибудь действительно заметил это в дикой природе?

Альтернативный вопрос

Возможно, никто не использует эту технику; если бы это правда тогда (как указывал Роб У.), то вопрос выше невозможен. Итак, мой альтернативный вопрос: каковы проблемы с этим подходом? Это может помочь объяснить, почему оно не было принято.

Как я вижу, для этого подхода по сравнению с JSONP существует как минимум два преимущества.

С JSONP вы доверяете script из чужого источника для запуска в вашем домене. С помощью window.name любые скрипты, включенные вредоносным сайтом, будут работать в собственном домене.
С JSONP невозможно передать большие данные (что-то слишком большое для URL-адреса), и нет способа сделать HTTP POST. С помощью window.name мы можем публиковать произвольные данные любого размера.

Каковы недостатки?

Пример реализации

Вот очень простой пример реализации клиента. Это не обрабатывает запросы POST, а только GET.

function fetchData(url, callback) {
    var frame = document.createElement('iframe');
    frame.onload = function() {
        frame.onload = function() {
            callback(frame.contentWindow.name);
            frame.parentNode.removeChild(frame);
        }
        frame.src = 'about:blank';
    }
    frame.src = url;
    document.body.appendChild(frame);
}

// using it

fetchData('http://somehost.com/api?foo=bar', function(response) {

    console.log(response);

});

Я установил скрипт, чтобы протестировать его здесь. Он использует этот script в качестве тестового сервера.

Вот несколько более длинный пример, который может выполнять запросы POST: http://jsfiddle.net/n9Wnx/2/

Резюме

Насколько я могу судить, window.name не поймал передачу данных. Интересно, верно ли мое восприятие (таким образом, исходный вопрос), и если да, то интересно, почему это так. Я перечислил несколько преимуществ, которые window.name, по-видимому, имеют JSONP. Может ли кто-нибудь определить некоторые недостатки, которые могли бы способствовать предотвращению принятия этой техники?

В целом, может ли кто-нибудь дать мне вескую причину, почему я не должен использовать winow.name в качестве транспорта данных?

Ответ 1