Строго говоря, пока у вас нет 100% контроля на устройством (как его нет ни в случае iOS, ни в случае Android), говорить о том, что это чисто ваш промах не до конца корректно. Теоретически, кейлогер могут установить на заводе, в магазине или где-то в недрах Apple, или Google или Huawei и ему подобные. Кроме того существуют уязвимости нулевого дня, и опять же ваша вина будет только в том, что вы оказались в сети.
Превентивные меры в вышеописанных ситуациях тоже неясно, какие можно предпринять.
По этой же логике двухфакторка тоже несекьюрна в принципе, т.к. любой, кто у установил слежение за вашим устройством (например, перехват ввода с клавиатуры) и к вашим СМС может с легкостью получить доступ к данным.
Тут корректнее говорить, о вероятности и сложности получения доступа. И тут вы, безусловно, правы. Двухфакторка значительно надёжднее. Но она — некоторый компромисс с удобством пользователя, и упомянутые Telegram/Viber/WhatsApp на него не идут, оставляя только СМС. За что, кстати, Телеграм уже платился.
Но, если у вас не такое критичное и важное приложение как мессенджер или инернет-банк, то, в целом, можно и пойти на этот риск. Конечно, если ценность ваших конкретных данных (к примеру, в приложениях такси) не сопоставима с затратами на перехват СМС.
Вот тут и тут дискуссии на эту тему. Краткий вывод такой:
The only reason I could think of that would encourage the use of AccountManager would be if you want to share your account across a number of different apps, as the data is stored in the central Android datastore which can be accessed by all apps. However, if this isn't required, I think its probably easier and simpler to just use SharedPreferences
Т.е. если вам не нужно ваши данные аутентификации синхронизировать между многими приложениями, то да — Account Manager, если нет (что значительно чаще. если вы не Яндекс, Google и т.п.), то проще обойтись SharedPreferences.
Да, вы правы насчёт ограничения или задержки. Просто важно об этом помнить. Я обновил статью и добавил раздел "Безопасность". Процитирую кусочек:
Посмотрим на примере. Пусть код TOTP состоит из 6 цифр — это 1000000 возможных вариантов. И пусть разрешено вводить 1 код в 1 секунду, а код живёт 30 секунд.
Шанс, что за 30 попыток в 30 секунд будет угадан код — 3/100000 ~ 0.003%. Казалось бы мало. Однако, таких 30-ти секундных окон в сутках — 2880 штук. Итого, у нас вероятность угадать код (даже несмотря на то, что он меняется) = 1 — (1 — 3/100000)^2880 ~ 8.2%. 10 дней таких попыток уже дают 57.8% успеха. 28 дней — 91% успеха.
Спасибо, что затронули эту тему. Обновил статью, и добавил раздел Безопасность, где дан ответ на тему противостояние прямому перебору. Перечислил два подхода, которые рекомендуются авторами стандарта.
Конечно, не точно. Насколько мне известно Telegram/Viber/WhatsApp не раскрывают особенностей серверной архитектуры в этой части. Если это не так — прошу меня поправить.
У статьи, грубо говоря, следующий посыл: если вы хотите организовать нечто похожее, но не знаете как — то вам сюда.
P.S. Немножко дополнил введение и в разделе про OTP добавил описание HOTP — это больше похоже на то, что используется в Telegram.
С большим энтузиазмом пошёл всех пересаживать на Tox, когда видео в скайпе стало выдавать задержки и потерю кадров, но оказалось, что у Tox дела обстоят ещё хуже. При не очень хорошем соединении uTox и qTox выдавали заметно худшее качество картинки, чем Skype.
В скайп есть какая-то грамотная подстройка битрейта (или, я не знаю, алгоритма кодирования) под мгновенную ширину канала. Tox, судя по всему, шпарит как есть.
Во-первых, с открытыми исходниками и т.п. — прямая дорога в краудфандинг. Но тут, я думаю, вы и сами уже догадались.
Во-вторых, вопрос: можно ли совместить использование этой одной базы на Пастильде с базами на другом устройстве? К примеру, удобно было бы работать с пастильдой на ноутбуке или компьютере, но переставлять в телефон — не очень. Было бы круто иметь возможность синхронизации.
Это всё обсуждалось в комментариях тут множество раз. Для VIM есть куча плагинов, которые делают эту работу, в т.ч. посредством анализа кода, в т.ч. для динамически типизированных языков.
Моё мнение, нужны не общие слова (вроде тех, что вы привели), а конкретные примеры для конкретных языков, где <ФИЧА> не работает или работает плохо в VIM, работает отлично в IDE, и где объяснено, почему <ФИЧА> — это очень полезная вещь, и как она ускоряет/облегчает процесс разработки.
Если честно, после такого громкого заголовка ожидал увидеть примеры, на которых IDE наголову бьёт VIM (набором плагинов для языка).
К сожалению, ничего сверх процитированного
Принципиально IDE от редактора отличается тем, что IDE оперирует синтаксическим деревом редактируемого кода на целевом языке (или неким к нему приближением), а редактор оперирует символами и строками.
почерпнуть из текста не удалось :(
Очень хочется уже нормального разбора от приверженца IDE, который покажет примеры из жизни программиста, в которых без возможностей IDE (которых нет в VIM) — ну никак. Хочется увидеть особенности вашего рабочего процесса (workflow, если хотите). Хочется, чтобы в нём существенно были задействованы фишки IDE, хочется, чтобы было видно, что они экономят вам человеко-часы. Чтобы IDE делало рутинную работу за вас и т.п.
Жду вот такого материала.
А разоблачения в стиле "VIM — редактор текста", и "голый VIM малопригоден для программиста, в то время как в IDE анализатор кода!!!". Ну право слово, даже обидно как-то.
Эх, где ж вы раньше были :) Уже успел запороть свой jolla phone, теперь один вариант — использовать чужие образы. Остаётся вопрос — где гарантия добросовестности тех людей, что делали этот образ?
В VIM есть неплохой плагин для TODO. VIM покрывает и этот функционал. Есть функционал календаря, и тоже неплохо работает. И т.д. и т.п… И да, это как-то отдалённо можно связать с разработкой (ведь разработчику надо где-то записывать задачи и планировать свой день), но это не имеет никакого отношения к дискуссии.
До того, как вы упомянули о озвученной функции, мне тоже казалось, что она не имеет отношения к дискуссии, т.к., мне казалось, не должно иметь отношения к процессу разработки. И под управлением проектом, я понимал что-то другое. Но я не истина в последней инстанции, безусловно. И в вашем, например, случае я ошибался. Если вам удобно так работать и IDE решает вашу проблему — то я очень за вас рад.
Отмечу только, что для VIM есть несколько плагинов для решения вашей проблемы (если, повторюсь, я её верно понял), вот например с видеодемонстрацией.
Ну мы обсуждаем преимущества и недостатки IDE и VIM для разработчика. Вы формулируете ситуацию, в которой с вашей точки зрения IDE удобнее. Я вам указываю, что ситуация нетипичная для разработки, более того, если я правильно понял, что вы имеете ввиду (правка кода на боевых серверах), противоречит общепринятым стандартам. Грубо говоря, удобство IDE в такой ситуации безусловный плюс, но относится ли это к делу?
Вопрос не в цене. Вопрос в том, зачем что-то делать, если можно этого не делать? Конкретно работая в VIM я могу себе позволить не думать о железе 10 (прописью, десять) лет. Т.е. в течение 10-ти лет мой выбор VIM в качестве основного инструмента разработки позволяет забыть о такой проблеме, как вынужденное обновление рабочей станции (конкретно в моём случае, ноутбука). На мой взгляд, это преимущество. Им можно пользоваться или нет, но это другой вопрос. Или вы не согласны?
Насчёт JetBrains, я выше писал, что я ушёл с IDE, не попробовав продкты JetBrains (если не ошибаюсь, они стали по-настоящему популярны только в последние годы), поэтому, действительно, допускаю, что многое стало сильно лучше.
А по поводу полиции IDE, я не до конца вас понимаю, вы считаете, что существует IDE, которая поддерживает всевозможные ЯП? Или, что существуют две, которые в сумме покрывают весь спектр? Или хотя бы столько, сколько поддерживает VIM? Потому что, если это вдруг не так (моя ставка), то я подберу вам 3 ЯП, для которых надо будет 3 IDE.
Ну а вообще, судя по тому же JetBrains, то на каждый ЯП своя IDE.
Во-первых, это только один из девяти аргументов. К остальным претензий нет?
Во-вторых, я не до конца вас понимаю: вы считаете, что то, что VIM потребляет меньше ресурсов и менее требователен к рабочей станции, минусом?
Не совсем понимаю вашу проблему. Вы выступаете в роли администратора или разработчика? Во втором варианте, мне пока неясно, в какой ситуации вам надо в одном месте консолидировать код с 10-ти разных мест и что-то с ним делать. Такое ощущение, что у вас как-то не так деплой налажен, но могу ошибаться.
Строго говоря, пока у вас нет 100% контроля на устройством (как его нет ни в случае iOS, ни в случае Android), говорить о том, что это чисто ваш промах не до конца корректно. Теоретически, кейлогер могут установить на заводе, в магазине или где-то в недрах Apple, или Google или Huawei и ему подобные. Кроме того существуют уязвимости нулевого дня, и опять же ваша вина будет только в том, что вы оказались в сети.
Превентивные меры в вышеописанных ситуациях тоже неясно, какие можно предпринять.
По этой же логике двухфакторка тоже несекьюрна в принципе, т.к. любой, кто у установил слежение за вашим устройством (например, перехват ввода с клавиатуры) и к вашим СМС может с легкостью получить доступ к данным.
Тут корректнее говорить, о вероятности и сложности получения доступа. И тут вы, безусловно, правы. Двухфакторка значительно надёжднее. Но она — некоторый компромисс с удобством пользователя, и упомянутые Telegram/Viber/WhatsApp на него не идут, оставляя только СМС. За что, кстати, Телеграм уже платился.
Но, если у вас не такое критичное и важное приложение как мессенджер или инернет-банк, то, в целом, можно и пойти на этот риск. Конечно, если ценность ваших конкретных данных (к примеру, в приложениях такси) не сопоставима с затратами на перехват СМС.
Вот тут и тут дискуссии на эту тему. Краткий вывод такой:
Т.е. если вам не нужно ваши данные аутентификации синхронизировать между многими приложениями, то да — Account Manager, если нет (что значительно чаще. если вы не Яндекс, Google и т.п.), то проще обойтись SharedPreferences.
Да, вы правы насчёт ограничения или задержки. Просто важно об этом помнить. Я обновил статью и добавил раздел "Безопасность". Процитирую кусочек:
Шанс, что за 30 попыток в 30 секунд будет угадан код — 3/100000 ~ 0.003%. Казалось бы мало. Однако, таких 30-ти секундных окон в сутках — 2880 штук. Итого, у нас вероятность угадать код (даже несмотря на то, что он меняется) = 1 — (1 — 3/100000)^2880 ~ 8.2%. 10 дней таких попыток уже дают 57.8% успеха. 28 дней — 91% успеха.
Это вроде как и есть brute force или вы что-то ещё имели ввиду?
Спасибо, что затронули эту тему. Обновил статью, и добавил раздел Безопасность, где дан ответ на тему противостояние прямому перебору. Перечислил два подхода, которые рекомендуются авторами стандарта.
Конечно, не точно. Насколько мне известно Telegram/Viber/WhatsApp не раскрывают особенностей серверной архитектуры в этой части. Если это не так — прошу меня поправить.
У статьи, грубо говоря, следующий посыл: если вы хотите организовать нечто похожее, но не знаете как — то вам сюда.
P.S. Немножко дополнил введение и в разделе про OTP добавил описание HOTP — это больше похоже на то, что используется в Telegram.
В скайп есть какая-то грамотная подстройка битрейта (или, я не знаю, алгоритма кодирования) под мгновенную ширину канала. Tox, судя по всему, шпарит как есть.
Во-первых, с открытыми исходниками и т.п. — прямая дорога в краудфандинг. Но тут, я думаю, вы и сами уже догадались.
Во-вторых, вопрос: можно ли совместить использование этой одной базы на Пастильде с базами на другом устройстве? К примеру, удобно было бы работать с пастильдой на ноутбуке или компьютере, но переставлять в телефон — не очень. Было бы круто иметь возможность синхронизации.
Это всё обсуждалось в комментариях тут множество раз. Для VIM есть куча плагинов, которые делают эту работу, в т.ч. посредством анализа кода, в т.ч. для динамически типизированных языков.
Моё мнение, нужны не общие слова (вроде тех, что вы привели), а конкретные примеры для конкретных языков, где <ФИЧА> не работает или работает плохо в VIM, работает отлично в IDE, и где объяснено, почему <ФИЧА> — это очень полезная вещь, и как она ускоряет/облегчает процесс разработки.
Прикручивали, кстати, eclim к VIM? Работает?
Если честно, после такого громкого заголовка ожидал увидеть примеры, на которых IDE наголову бьёт VIM (набором плагинов для языка).
К сожалению, ничего сверх процитированного
почерпнуть из текста не удалось :(
Очень хочется уже нормального разбора от приверженца IDE, который покажет примеры из жизни программиста, в которых без возможностей IDE (которых нет в VIM) — ну никак. Хочется увидеть особенности вашего рабочего процесса (workflow, если хотите). Хочется, чтобы в нём существенно были задействованы фишки IDE, хочется, чтобы было видно, что они экономят вам человеко-часы. Чтобы IDE делало рутинную работу за вас и т.п.
Жду вот такого материала.
А разоблачения в стиле "VIM — редактор текста", и "голый VIM малопригоден для программиста, в то время как в IDE анализатор кода!!!". Ну право слово, даже обидно как-то.
А есть, кстати, IDE, где не тормозит?
Сходу гуглится для Fantom и K.
Насчёт качества автодополнения, в некоторых языках, к сожалению, VIM заметно проигрывает, это правда.
В VIM есть неплохой плагин для TODO. VIM покрывает и этот функционал. Есть функционал календаря, и тоже неплохо работает. И т.д. и т.п… И да, это как-то отдалённо можно связать с разработкой (ведь разработчику надо где-то записывать задачи и планировать свой день), но это не имеет никакого отношения к дискуссии.
До того, как вы упомянули о озвученной функции, мне тоже казалось, что она не имеет отношения к дискуссии, т.к., мне казалось, не должно иметь отношения к процессу разработки. И под управлением проектом, я понимал что-то другое. Но я не истина в последней инстанции, безусловно. И в вашем, например, случае я ошибался. Если вам удобно так работать и IDE решает вашу проблему — то я очень за вас рад.
Отмечу только, что для VIM есть несколько плагинов для решения вашей проблемы (если, повторюсь, я её верно понял), вот например с видеодемонстрацией.
Ну мы обсуждаем преимущества и недостатки IDE и VIM для разработчика. Вы формулируете ситуацию, в которой с вашей точки зрения IDE удобнее. Я вам указываю, что ситуация нетипичная для разработки, более того, если я правильно понял, что вы имеете ввиду (правка кода на боевых серверах), противоречит общепринятым стандартам. Грубо говоря, удобство IDE в такой ситуации безусловный плюс, но относится ли это к делу?
Вопрос не в цене. Вопрос в том, зачем что-то делать, если можно этого не делать? Конкретно работая в VIM я могу себе позволить не думать о железе 10 (прописью, десять) лет. Т.е. в течение 10-ти лет мой выбор VIM в качестве основного инструмента разработки позволяет забыть о такой проблеме, как вынужденное обновление рабочей станции (конкретно в моём случае, ноутбука). На мой взгляд, это преимущество. Им можно пользоваться или нет, но это другой вопрос. Или вы не согласны?
Насчёт JetBrains, я выше писал, что я ушёл с IDE, не попробовав продкты JetBrains (если не ошибаюсь, они стали по-настоящему популярны только в последние годы), поэтому, действительно, допускаю, что многое стало сильно лучше.
А по поводу полиции IDE, я не до конца вас понимаю, вы считаете, что существует IDE, которая поддерживает всевозможные ЯП? Или, что существуют две, которые в сумме покрывают весь спектр? Или хотя бы столько, сколько поддерживает VIM? Потому что, если это вдруг не так (моя ставка), то я подберу вам 3 ЯП, для которых надо будет 3 IDE.
Ну а вообще, судя по тому же JetBrains, то на каждый ЯП своя IDE.
Во-первых, это только один из девяти аргументов. К остальным претензий нет?
Во-вторых, я не до конца вас понимаю: вы считаете, что то, что VIM потребляет меньше ресурсов и менее требователен к рабочей станции, минусом?
Не совсем понимаю вашу проблему. Вы выступаете в роли администратора или разработчика? Во втором варианте, мне пока неясно, в какой ситуации вам надо в одном месте консолидировать код с 10-ти разных мест и что-то с ним делать. Такое ощущение, что у вас как-то не так деплой налажен, но могу ошибаться.