Здравствуйте, Pavel Dvorkin, Вы писали:

PD>Здравствуйте, gandjustas, Вы писали:

G>>А ты webapps не видел? Сделали уже, около 40% функций десктопной реализует. Для аутлука почти 100%.потому что owa появилась в 1996 году, а webapps в 2010.

PD>Outlook не аргумент, почта — примитив по сравнению с редактированием. В сущности, в почтовом десктопном клиенте уже лет 15 по большому счету ничего не меняется, нечего там менять.
Word\Excel за последние 8 лет тоже не сильно поменялись функционально, вот только в вебе их почти никто не делал, поэтому убого. А почта в вебе давно существует, поэтому с дсктопом почти паритет.

G>>Причём если бы изначально офис делали для веба, то ситуация получилась бы обратная.

PD>Вряд ли. Во времена DOS, когда Word начался, его просто не могли делать. Да и до Word редакторов хватало, и до Excel электронные таблицы были, так что MS должна была уже тогда как минимум их возможности повторить. А Web тогда был в состоянии статических страниц.
Ну вот ты сам видишь какие причины были тогда. А сейчас они есть? Вообще-то нет.


PD>>>А вот их, судя по всему, при нынешнем подходе к web-приложениям, просто нельзя сделать. Заметь, я не говорю "вообще нельзя". В принципе ясно, что можно. Только здесь надо заново продумать, что будет делаться на клиенте, а что на сервере, и как они обмениваться данными будут.
G>>Да все можно, на сервере надо минимум.

PD>Можно, но именно минимум. А сейчас не минимум.

PD>>>Вот есть такой текстовый редактор UltraEdit. Редактирует текстовые файлы любой длины, я с его помощью редактировал csv в сотни Мб. Ясно, что механизм отсылки этого файла на сервер и редактирования там с последующей отсылкой результата на клиент не проходит. Но на клиенте он вполне мог бы редактироваться и в web приложении, если бы web-приложение имело право прямо писать на клиент. А оно не имеет права по известным причинам...
G>>Ты про FileApi не в курсе? Твои знания устарели года на 3, почитай что браузеры сейчас умеют, удивишься...

PD>Не был в курсе. Спасибо. Посмотрел. Только вот такой вопрос

PD>http://www.w3.org/TR/FileAPI/

PD>FileReader там есть. А вот FileWriter я не нашел. Его нет ? Если нет, то для редактирования на клиенте это не годится — см. выше мой пример с UltraEdit хотя бы, да и не только.
http://www.w3.org/TR/file-system-api/

Вот только не поддерживается пока никем: http://caniuse.com/#feat=filesystem
Поэтому делают storage на сервере и webdav

Для начала нужно определиться, что считать веб-приложением.

RSDN@HOME это веб-приложение или нет?
Приложения, поднимающие локальные HTTP-сервера, это веб или нет?
Приложения на Flash, Silverlight, ActiveX, Java Applets?

Есть, например, такое поделие для электронного документооборота — DocsVision от Digital Design. Это приложение работает в окне браузера (IE only), но UI у него сделан из обычных формочек a la Windows Forms. С другой стороны все данные живут на сервере. Это веб-приложение?

Здравствуйте, gandjustas, Вы писали:

PD>>Outlook не аргумент, почта — примитив по сравнению с редактированием. В сущности, в почтовом десктопном клиенте уже лет 15 по большому счету ничего не меняется, нечего там менять.
G>Word\Excel за последние 8 лет тоже не сильно поменялись функционально, вот только в вебе их почти никто не делал, поэтому убого.

Ну как же никто ? И Google, и MS. Но убого. Уж MS-то сделать хотела бы не хуже, чем Word, да вот не может. Впрочем, Google тоже — десктопного редактора-то у них нет, отобрать бы весь рынок у MS Office — дело святое. Да вот не получается.

>А почта в вебе давно существует, поэтому с дсктопом почти паритет.

Задача относительно более простая, чем редактирование. В сущности, 95% — это перекачка файлов, просмотр их и простенький текстовый редактор. За всем остальным (хотя бы просмотр вложений) — в обоих случаях десктопное приложение (или нативный плугин) извольте иметь)


G>>>Причём если бы изначально офис делали для веба, то ситуация получилась бы обратная.

PD>>Вряд ли. Во времена DOS, когда Word начался, его просто не могли делать. Да и до Word редакторов хватало, и до Excel электронные таблицы были, так что MS должна была уже тогда как минимум их возможности повторить. А Web тогда был в состоянии статических страниц.
G>Ну вот ты сам видишь какие причины были тогда. А сейчас они есть? Вообще-то нет.

Я же не говорю, что сделать _в_принципе нельзя. В принципе можно. Но нет их пока. Я и в первом ответе не сказал, что в принципе убого. На данный момент убого.



G>Вот только не поддерживается пока никем: http://caniuse.com/#feat=filesystem
G>Поэтому делают storage на сервере и webdav

Ну вот и попробуй этот самый csv на сотни Мб гонять с сервера на клиент... Или картинку пусть даже в десятки Мб. Или (о ужас!) фильм какой-нибудь.

А работать на клиенте не получается именно из-за запрета записи на клиент. Вот тут принципиальная проблема. Если я запускаю десктопную программу, скачанную с сайта MS, то я знаю, что она от MS, им я доверяю, и программу запускаю. Конечно, баги возможны, в том числе и всякие уязвимости, но тем не менее я запускаю программу, которой можно доверять. А вот если у меня в броузере работает JS, то доверять ему нельзя, так как нет никакой гарантии, что он не от MS, а бог знает откуда. Пока эту проблему не решат — о серьезной работе с FS на клиенте речи идти не может.

А второй момент — идея работы на сервере вообще-то достаточно неразумна. Чем он, сервер, лучше моей машины ? Там Intel и здесь Intel, у меня 8 Гб, так и там мне не 256 Гб дадут, да и не нужны они мне. Словом, у меня машина ничем не хуже, чем одна машина из их кластера, почему же надо операции на сервере делать ? На сервере минимум должен делаться, а тяжелые действия на клиенте.

Здравствуйте, Pavel Dvorkin, Вы писали:

PD>Здравствуйте, gandjustas, Вы писали:

>>А почта в вебе давно существует, поэтому с дсктопом почти паритет.
PD>Задача относительно более простая, чем редактирование. В сущности, 95% — это перекачка файлов, просмотр их и простенький текстовый редактор. За всем остальным (хотя бы просмотр вложений) — в обоих случаях десктопное приложение (или нативный плугин) извольте иметь)
Посмотри с другой сторны. Facebook например или вконтактик. Очень пригодилось бы дестопное приложение, которое локально закачивает основные ресурсы и позволяет оффлайново смотреть + минимальный трафик для пересылки сообщений.
Апи вроде уже давно есть, а нормальных приложений днем с огнем не найти.

Тоже исторический фактор. Чтобы сейчас сделать десктоп версию, сравнимую с веб надо вбухать десяток человеколет. Оно как минимум не окупится. Поэтому никто не занимается.
Это и называется историческим фактором. Функционал тут совершенно не при чем.

G>>>>Причём если бы изначально офис делали для веба, то ситуация получилась бы обратная.

PD>>>Вряд ли. Во времена DOS, когда Word начался, его просто не могли делать. Да и до Word редакторов хватало, и до Excel электронные таблицы были, так что MS должна была уже тогда как минимум их возможности повторить. А Web тогда был в состоянии статических страниц.
G>>Ну вот ты сам видишь какие причины были тогда. А сейчас они есть? Вообще-то нет.

PD>Я же не говорю, что сделать _в_принципе нельзя. В принципе можно. Но нет их пока. Я и в первом ответе не сказал, что в принципе убого. На данный момент убого.
А какая разница? Когда соберешься приложение делать ты будешь смотреть на опыт 10-летней давности или на современные возможности?



G>>Вот только не поддерживается пока никем: http://caniuse.com/#feat=filesystem
G>>Поэтому делают storage на сервере и webdav

PD>Ну вот и попробуй этот самый csv на сотни Мб гонять с сервера на клиент... Или картинку пусть даже в десятки Мб. Или (о ужас!) фильм какой-нибудь.
Зачем весь файл гонять? Гоняй кусками. Например office 2013 это уже делает с SharePoint 2013. Передает не вейсь файл, а только изменившиеся части. А частичная закачка в HTTP всегда была.


PD>А работать на клиенте не получается именно из-за запрета записи на клиент. Вот тут принципиальная проблема. Если я запускаю десктопную программу, скачанную с сайта MS, то я знаю, что она от MS, им я доверяю, и программу запускаю. Конечно, баги возможны, в том числе и всякие уязвимости, но тем не менее я запускаю программу, которой можно доверять. А вот если у меня в броузере работает JS, то доверять ему нельзя, так как нет никакой гарантии, что он не от MS, а бог знает откуда. Пока эту проблему не решат — о серьезной работе с FS на клиенте речи идти не может.
HTTPS не? SOP не для тебя придумали?
Ты довольно слабо ориентируешься в веб-технологиях, чтобы судить о таких вещах.
Кстати при использовании доступа к ФС тебя спросят дополнительно. Причем левые скрипты, загруженные из других источников, не получат доступ к твоему компу.

PD>А второй момент — идея работы на сервере вообще-то достаточно неразумна. Чем он, сервер, лучше моей машины ? Там Intel и здесь Intel, у меня 8 Гб, так и там мне не 256 Гб дадут, да и не нужны они мне. Словом, у меня машина ничем не хуже, чем одна машина из их кластера, почему же надо операции на сервере делать ? На сервере минимум должен делаться, а тяжелые действия на клиенте.
Зависит от приложения, тут однозначно ничего сказать нельзя.

Здравствуйте, gandjustas, Вы писали:

G>Посмотри с другой сторны. Facebook например или вконтактик. Очень пригодилось бы дестопное приложение, которое локально закачивает основные ресурсы и позволяет оффлайново смотреть + минимальный трафик для пересылки сообщений.


Фейсбук показывает рекламу?

Здравствуйте, gandjustas, Вы писали:

G>Посмотри с другой сторны. Facebook например или вконтактик. Очень пригодилось бы дестопное приложение, которое локально закачивает основные ресурсы и позволяет оффлайново смотреть + минимальный трафик для пересылки сообщений.
G>Апи вроде уже давно есть, а нормальных приложений днем с огнем не найти.

Ну как сказать. Для RSDN вроде есть оффлайн-клиент. Почему там нет — не знаю. Но это опять же : перекачка плюс просмотр. Больше практически ничего. Перекачка в любом случае сетевая, а просмотр довольно примтивен. Может, поэтому и нет оффлайн-клиента.

G>Тоже исторический фактор. Чтобы сейчас сделать десктоп версию, сравнимую с веб надо вбухать десяток человеколет. Оно как минимум не окупится. Поэтому никто не занимается.
G>Это и называется историческим фактором. Функционал тут совершенно не при чем.

Не соглашусь. Во-первых, десяток человеко-лет — это не то, что немного, а совсем немного. Команда из 10 человек на год для MS — пустяк. Сделали бы без проблем, если бы смысл был.


PD>>Я же не говорю, что сделать _в_принципе нельзя. В принципе можно. Но нет их пока. Я и в первом ответе не сказал, что в принципе убого. На данный момент убого.
G>А какая разница? Когда соберешься приложение делать ты будешь смотреть на опыт 10-летней давности или на современные возможности?

Обсуждалось нынешнее состояние web приложений. Причем именно состояние, а не потенциальные возможности. Они пока что потенциальны, а не реальны. Когда будет иное состояние — будет иной разговор.

PD>>Ну вот и попробуй этот самый csv на сотни Мб гонять с сервера на клиент... Или картинку пусть даже в десятки Мб. Или (о ужас!) фильм какой-нибудь.
G>Зачем весь файл гонять? Гоняй кусками. Например office 2013 это уже делает с SharePoint 2013. Передает не вейсь файл, а только изменившиеся части. А частичная закачка в HTTP всегда была.

Так ведь его сначала закачать на сервер надо. А по хорошему и не надо вовсе. Его вполне на клиенте можно обрабатывать.


G>HTTPS не? SOP не для тебя придумали?
G>Ты довольно слабо ориентируешься в веб-технологиях, чтобы судить о таких вещах.

Наверное да, это не моя тематика. Я просто сужу о факте — обработки на клиенте нет.

G>Кстати при использовании доступа к ФС тебя спросят дополнительно. Причем левые скрипты, загруженные из других источников, не получат доступ к твоему компу.

Хорошо, если так. Пример можно ? Посмотрю.

PD>>А второй момент — идея работы на сервере вообще-то достаточно неразумна. Чем он, сервер, лучше моей машины ? Там Intel и здесь Intel, у меня 8 Гб, так и там мне не 256 Гб дадут, да и не нужны они мне. Словом, у меня машина ничем не хуже, чем одна машина из их кластера, почему же надо операции на сервере делать ? На сервере минимум должен делаться, а тяжелые действия на клиенте.
G>Зависит от приложения, тут однозначно ничего сказать нельзя.

Однозначно, конечно, нет, мало ли что там нужно сделать. Но для того, что делает Фотошоп — однозначно да. Делает же он

Здравствуйте, gandjustas, Вы писали:

G>Здравствуйте, Аноним, Вы писали:

А>>Здравствуйте, gandjustas, Вы писали:

G>>>Здравствуйте, Аноним, Вы писали:

А>>>>Здравствуйте, gandjustas, Вы писали:

G>>>>>Здравствуйте, Аноним, Вы писали:

G>>>>>Давай по отдельности:
G>>>>>1) Как кеширование значений влияет на безопасность?\
А>>>>можно подменить значение на клиенте и вмешаться в логику работы, а как это влияет на безопасность думаю объяснять не надо
G>>>Если значение кеша влияет на логику, то это уже не кеш, а что-то странное. У тебя быстрее другие проблемы возникнут при таком подходе.

А>>Кэш в любом случае влияет на логику, т.к. он используется в каком либо коде, иначе он не нужен вообще.
G>А что мешает кеш в толстом клиенте поправить у десктопного приложения, если он на логику влияет? В чем разница с вебом будет?
Разница в том что легко подменить логику создав новый скрипт или в режиме отладки изменить. Для подобного действия с скомпилированным кодом , при наличии защиты от отладки требуется намного большие компетенции.


G>>>>>2) Как количество эндпоинтов влияет на безопасность?
А>>>>тут вопрос риторический, если знаком с теорией вероятностей то ответ очевиден. Каждый ендпоинт — дыра с определенным % критичных проблем, больше endpoint — больше общий % и возможностей для маневра.
G>>>Модель угроз не строится на теории вероятностей.
А>>Ага, только причем тут модель угроз, речь о вероятности взлома, которая увеличивается от количества дырок.
G>Если у тебя нет модели угроз, то как ты можешь вероятность чего-либо найти? Прочитай чтонить про ИБ для начала. У тебя очень дилетантские суждения.
Пока что дилетант это ты, т.к. не понимаешь простых вещей, что любой метод торчащий наружу это находка для злоумышленника, и какието демагогии про модели, модель тут банальнейшая — возможность отправить кривые данные



G>>>>>>>Для скорости ввода хоткеи тоже не нужны. нужно использование клавиш Tab, Enter и пробел.
А>>>>>>Для скорости ввода нужны хоткеи , чтобы бысро переключаться между группами контролов , если 40 полей — вместо того чтобы перейти к нужному полю по Alt-(ключслово) , придется 40 раз нажать tab ? нет спасибо.
G>>>>>Если у тебя 40 контролов и тебе более 80% надо ввести, тогда хоткеи тебе не помогут, все равно все надо вводить данные.ъ
А>>>>Ага, а если я ввел неправильно фамилию в 1м контроле , потом на середине это замечено и нужно исправить ? Табом лезть 20 нажатий ? Иногда при таком подходе случайно можно пролететь мимо и опять круг в 40 контролов давать. Нет уж спасибо.
G>>>Про shift+tab не в курсе?
А>>Какая разница 20 нажатий вверх, или вниз. Проблемы которые описаны остануться.
G>Промахнуться не проблема, а кнопку tab можно ооооочень быстро нажимать. Не обращал внимание как в ПФ в досовском интерфейсе данные вбивают?

Чем быстрее жмешь тем больше шансов пролететь мимо, в досовском также есть ярлыки для полей как правило

G>>>Почитай about face алана купера.
А>>Скажи как сделать 3дмакс из 3х функций, потом говори глупости
G>Ты же не 3dmax делаешь, даже близко не похожее на него.
G>Почитай купера, там многие ответы на твои вопросы.
Откуда тебе знать что я делаю, телепат блин, я делаю многофункциональные приложения которые содержат сотни юзкейсов и операций.

Здравствуйте, <Аноним>, Вы писали:

Вот уж действительно, "смешались в кучу люди, кони..."

G>>>>>>2) Как количество эндпоинтов влияет на безопасность?

Ентрипоинтов. И то, что вы здесь обсуждаете называется защищенностью, а не безопасностью

А>>>>>тут вопрос риторический, если знаком с теорией вероятностей то ответ очевиден. Каждый ендпоинт — дыра с определенным % критичных проблем, больше endpoint — больше общий % и возможностей для маневра.

Это примерно то же самое, что сказать: "каждый метод — баг с определенным процентом критичных проблем", аргументируя необходимость минимизировать число методов в коде

G>>>>Модель угроз не строится на теории вероятностей.

Однако, анализ рисков (для которого эта модель и строится, собственно) оперирует вероятностью напрямую, рассматривая риск, как функцию от вероятности успешности атаки и потенциального ущерба. Правда Аноним похоже имел ввиду нечто совсем другое.

А>>>Ага, только причем тут модель угроз, речь о вероятности взлома, которая увеличивается от количества дырок.

Вероятность реализации той или иной угрозы (т.е. "взлома") не зависит от количества уязвимостей, т.к. равна 1.0 при появлении первой же из них.

G>>Если у тебя нет модели угроз, то как ты можешь вероятность чего-либо найти? Прочитай чтонить про ИБ для начала. У тебя очень дилетантские суждения.
А>Пока что дилетант это ты, т.к. не понимаешь простых вещей, что любой метод торчащий наружу это находка для злоумышленника, и какието демагогии про модели, модель тут банальнейшая — возможность отправить кривые данные

Во-первых, не стоит хамить друг-другу и пытаться уличить в некомпетентности. Замечание к обоим.

Во-вторых, Аноним вполне справедливо утверждает, что рост количества методов приводит к увеличению плоскости потенциальной атаки. А если быть точным, то не только и не столько методов, сколько их параметров, которыми может манипулировать атакующий. Т.е. отказ от ajax в пользу классической модели синхронных запросов ничего не даст — количество методов просто перейдет в количество их параметров, плоскость от этого не изменится. Слегка неправ Аноним в своем суждении о моделировании угроз. Стоило бы ознакомиться хотя бы с http://download.microsoft.com/download/9/3/5/935520EC-D9E2-413E-BEA7-0B865A79B18C/Introduction_to_Threat_Modeling.ppsx, прежде чем называть угрозой "возможность отправить кривые данные" (которая, к слову сказать, имеет место в сетевых приложениях вообще всегда, безотносительно веба и гуи). И совсем неправ Аноним в том, что считает будто на клиенте просто обязана быть реализована хоть какая-то бизнес логика, критичная к требованиям защищенности. Ничего не мешает реализовать такую логику на стороне сервера и получить вполне защищенное веб-приложение.

- Веб интерфейс не может на 100% использовать вычислительную мощь современных компьютеров, устанавливаемых у конечных пользователей.

— Нужно подстраиваться под разные браузеры. У каждого браузера есть особенности работы с HTML и javaScript.

— В RIA бизнес логика просачивается на уровень представления (на клиента в JavaScript).

— Ввиду того что веб сервисы это наборы методов (процедур), программирование часто становится процедурным. Полноценно использовать ООП в Web тяжело.

— JavaScript не типизированный, тяжело отлаживать, рефакторить

http://rsdn.ru/forum/job/4547080.1

Автор: igor-booch
Дата: 18.12.11

Здесь про облака, но разговор с maxkar ушел в эту тему:
http://rsdn.ru/forum/design/5149465.1

Автор: igor-booch
Дата: 25.04.13

Здравствуйте, igor-booch, Вы писали:

IB>- Веб интерфейс не может на 100% использовать вычислительную мощь современных компьютеров, устанавливаемых у конечных пользователей.

IB>- Нужно подстраиваться под разные браузеры. У каждого браузера есть особенности работы с HTML и javaScript.
Особенности нивелируются фреймворками.


IB>- В RIA бизнес логика просачивается на уровень представления (на клиента в JavaScript).
Это хорошо или плохо? или просто написано?

IB>- Ввиду того что веб сервисы это наборы методов (процедур), программирование часто становится процедурным. Полноценно использовать ООП в Web тяжело.
Это неправда, посмотри data access фреймворки. Там ООП даже больше, чем стоило бы.

IB>- JavaScript не типизированный, тяжело отлаживать, рефакторить
Неактуально, есть typescript\script#\gwt\coffescript\dart.

G>Особенности нивелируются фреймворками.
G>Это неправда, посмотри data access фреймворки. Там ООП даже больше, чем стоило бы.
G>Неактуально, есть typescript\script#\gwt\coffescript\dart.
То, что в десктопном клиенте
можно достичь средствами строго типизированного ООП ЯП и GUI-ядром ОС (то есть уже встроенное, родное),
в Web
можно достичь только через всякие сторонние фреймворки, часть из которых сырая или не поддерживается.

G>Там ООП даже больше, чем стоило бы.
Правильного ООП много не бывает.

G>Это хорошо или плохо? или просто написано?
А как у нас топик называется?

Здравствуйте, igor-booch, Вы писали:

G>>Особенности нивелируются фреймворками.
G>>Это неправда, посмотри data access фреймворки. Там ООП даже больше, чем стоило бы.
G>>Неактуально, есть typescript\script#\gwt\coffescript\dart.
IB>То, что в десктопном клиенте
IB>можно достичь средствами строго типизированного ООП ЯП и GUI-ядром ОС (то есть уже встроенное, родное),
IB>в Web
IB>можно достичь только через всякие сторонние фреймворки, часть из которых сырая или не поддерживается.
Конкретнее?


G>>Там ООП даже больше, чем стоило бы.
IB>Правильного ООП много не бывает.
Что считать "правильным" ?

G>Конкретнее?
Конкретней ты сам уже написал.


G>>>Там ООП даже больше, чем стоило бы.
IB>>Правильного ООП много не бывает.
G>Что считать "правильным" ?

Не считаю возможным ответить на данный вопрос кратко. Почитай соответствующую литературу.

Здравствуйте, igor-booch, Вы писали:

G>>>>Там ООП даже больше, чем стоило бы.
IB>>>Правильного ООП много не бывает.
G>>Что считать "правильным" ?
IB>
IB>Не считаю возможным ответить на данный вопрос кратко. Почитай соответствующую литературу.
Эта фраза потрясающе соотносится с твоей подписью.

На этом видимо можно заканчивать, адекватных аргументов больше не будет.

G>Эта фраза потрясающе соотносится с твоей подписью.
Ребенку то на кошках и собаках я объясню, чтобы у него было представление.
Но ребенок не программист и правильно программировать средствами ООП от этого не научится.
Ты хотел своим вопросом меня привести к тому, что правильного ООП не существует.
Доказывать обратное я тебе здесь не собираюсь.

BB>Используйте Веб-приложения, если:
BB> Требуется обеспечить простую модель развертывания в Веб.
BB> Приложение должно быть доступным через Интернет.

Немного не актуально: есть ClickOnce и xbap

Здравствуйте, igor-booch, Вы писали:

BB>>Используйте Веб-приложения, если:
BB>> Требуется обеспечить простую модель развертывания в Веб.
BB>> Приложение должно быть доступным через Интернет.

IB>Немного не актуально: есть ClickOnce и xbap

Да нет, актуально, просто четкой границы нет и критериев больше, а это были основные.
xpab и ClickOnce там тоже рассматривается: http://apparchguide.ms/

KV>Это примерно то же самое, что сказать: "каждый метод — баг с определенным процентом критичных проблем", аргументируя необходимость минимизировать число методов в коде
Правильно, чем меньше методов, тем проще архитектура, тем лучше, проще поддерживать, быстрее работает.
Программист должен бороться за простоту, а не за сложность.
Код должен настолько простым чтобы выполнять возложенные на него задачи, не проще и не сложнее.
Если допустить, что код выполняет возложенные задачи, то есть проще не получится,
то остается минимизация количества кода, то есть методов.

Здравствуйте, gandjustas, Вы писали:

G>Посмотри с другой сторны. Facebook например или вконтактик. Очень пригодилось бы дестопное приложение, которое локально закачивает основные ресурсы и позволяет оффлайново смотреть + минимальный трафик для пересылки сообщений.
G>Апи вроде уже давно есть, а нормальных приложений днем с огнем не найти.

Если не ошибаюсь, для FB на iPad клиент нативный.

P.S. Думаю, что оффлайн доступ на desktop-е для Facebook/vk малополезен.