Вы имели в виду, чтобы предоставить эксклюзивное право мошенничать чиновникам, плюс создать для них ещё один источник нелегального дохода?

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

Вероятно, что-нибудь на базе Double Ratchet Algorithm, напр.: используемый в XMPP OMEMO, Signal Protocol, Matrix…

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

Потребность есть, нет потребности что-то ради этого делать. Именно поэтому в телеграме шифруется мало чатов — потому что нужно нажать лишние кнопочки, да и вообще просто задуматься о необходимости их нажать. Плюс в десктопном клиенте они не поддерживаются, и в веб вроде тоже.

Что касается email, то TLS там никого не волнует вообще — кому нужна безопасность тот использует PGP/GPG.

В общем, суть в том, что шифрование должно работать из коробки, чтобы люди об этом не задумывались вообще. А когда задумываются — чтобы могли сверить отпечатки ключей удобным способом, чтобы убедиться что общаются именно с тем, с кем думают.

Посмотрите как выдавливают http и любой ценой заменяют на https. И на TLS в почте, да. Суть в том, что времена не шифрованных коммуникаций заканчиваются, поэтому чтобы выжить в ближайшие годы — нужна поддержка шифрования, причём не для гиков, а удобная и прозрачная настолько, чтобы обычные юзеры её использовали по умолчанию и толком даже не замечали этого.

IMHO без End-to-end шифрования, в т.ч. групповых чатов — точно не взлетит. Сложно или нет, но многие мессенджеры эту фичу уже осилили, кто-то лучше, что-то хуже, и пути назад уже нет. Что касается "что знают трое" — это, конечно, правда, но далеко не вся. Риск утечки увеличивается с ростом числа участников, но не становится равным 100% начиная с трёх человек. А вот число посторонних желающих получить информацию, которая их никак не касается — постоянно растёт. Пока это были только спец.службы — это было относительно терпимо, хотя в случае наших ещё и был шанс что информация от них уйдёт "налево" и попадёт к конкурентам. Но сейчас информацию хотя вообще все подряд, для показа рекламы, для продажи, просто на всякий случай чтоб было… End-to-end шифрование позволяет отсечь 99.999% любопытствующих, оставляя место только добровольному разглашению одним из участников (с чем можно бороться разными методами, от технических до юридических) либо утечке с заражённого малварью устройства одного из участников (с чем тоже можно бороться).

Кстати, а чем не устроил Matrix?

Вообще-то это сарказм был. Когда я искал первую работу php ещё и в проекте не было, но в остальном я согласен с nikweter.

open stackoverflow, copy, paste?

Т.е. причины переписывания истории в TON не имеют отношения к причинам, по которым это ранее требовалось в других блокчейнах (украли слишком уж много денег, баг в смартконтракте, etc.)?

Всё верно, но мне казалось мы тут обсуждаем количество разных вариантов объявления переменных — 2 их или 3. Их 2. А range это часть for и к этой теме вообще отношения не имеет.

А в чём отличия-то? range от строки возвращает не строку, а индекс символа и сам символ. Вы создаёте новую переменную с тем же именем и присваиваете туда возвращённое range значение.

Оператор := работает здесь ровно так же, как и в любом другом месте:

• требует чтобы слева была хоть одна новая переменная,
• затеняет существующую переменную в новой области видимости при необходимости,
• создаёт новые переменные,
• присваивает значения всем заданным переменным.

Это не частный случай, а абсолютно обычный. Вы же не считаете a := f() частным случаем a := 5?

Линтеры не используете, или затыкаете? А то некоторые на подчёркивания конкретно ругаются… и shadowing они, вообще-то, ловят на раз, так что особо напрягаться смысла мало.

Спасибо, я в курсе как устроен map. Но, ещё раз попытаюсь объяснить, правильные термины важны не сами по себе, а потому что они проясняют ситуацию. В нашем случае терминологически правильное заявление "map передаётся по значению" ничего не проясняет, а наоборот, запутывает. Разница между передачей по значению и по ссылке/указателя важна не потому, что описывает внутреннее устройство языка, а потому что показывает программисту чего ему ожидать — сможет ли вызванная функция изменить переданное ей значение, или нет. А когда термины вроде правильные, только ни разу не помогают понять что происходит — они бесполезны. А как только они становятся бесполезны — все становится плевать, каким словом что "правильно" называть.

Если под словами ссылка и указатель понимают одно и то же — нет, к неправильным выводам это не ведёт. Кроме того, если уже начинать придираться, то вообще-то кое-какие значения в Go — ещё те указатели. Да, формально всё передаётся по значению, но кому до этого есть дело, если на практике передача "по значению" map-а никак не мешает вызванной функции его изменять? А возможность изменять срез, но только частично — это вообще бомба. Ещё каналы, но с ними сложно придумать кейс с неожиданным поведением кода из-за неявной передачи указателя, как в предыдущих двух случаях.

Что-то I2P… да пофигу, пусть уже хоть кто-то наконец-то реально распространит эти технологии, а называть он это может как угодно, и будут ли юзеры знать чем пользуются — тоже не принципиально.

Я, конечно, люблю Go, и люблю называть вещи своими именами, даже очень. И я читал http://spf13.com/post/go-pointers-vs-references/. Но, по-моему, Вы всё-таки перегибаете палку. Если разработчик писал на плюсах, где есть и то и другое, то он, предположительно, разбирается в отличиях и не запутается с указателями в Go. Всем остальным — пофигу. У меня до Go в опыте разные языки, от ассемблера до перла, но плюсов нет, и ни в одном из моих языков ссылок как в плюсах не было — зато во многих были указатели, где с адресной арифметикой, где без. И называли их в половине случаев — ссылками. По настроению, в основном. Могли в одном и том же предложении одну и ту же переменную назвать и ссылкой и указателем. И никогда это не вызывало проблем с пониманием. (Более того, в перле, кстати, что-то подобное ссылкам плюсов таки есть — только называют их алиасами, и реализованы они не столько в самом языке, сколько в отдельной библиотеке.) В общем, называть вещи своими именами важно, но здесь и сейчас Вы — перегибаете.

Мне вот просто любопытно — зачем Вы подчёркивания используете?

Спасибо, читал ещё когда она вышла. Как по мне — не очень актуально, если система скомпрометирована и там работает кейлоггер, то оппаньки. Пытаться защищаться можно, но по факту проще предотвратить изначальный взлом системы, чем бороться с последствиями. У меня KeePassXC и линух. Он использует вроде какие-то доп.меры предосторожности вроде защиты секретных значений в памяти, etc. Но я больше полагаюсь на hardened ядро ОС, регулярные обновления, файрвол и тщательный выбор всех сервисов/приложений, которые доступны по сети (браузер прикрывает, в основном, uMatrix).

По сути будет возможность делать те же запросы, но по новому протоколу.

Могу ошибаться, но по-моему и из iOS и из Android уже некоторое время как выпилили возможность поддерживать постоянное сетевое соединение. Чтобы что-то передать по своей инициативе приложение должно сначала "проснутся", и делать это по своей инициативе и достаточно регулярно — довольно проблематично. А чуть ли не единственный способ принять что-то по инициативе кого-то другого — получить штатное пуш-уведомление от серверов гугла/эппла.

Для работы обычного мессенджера это не очень критично (статус "онлайн" поддерживать проблематично, но всё остальное работает без проблем), а вот для работы P2P протокола условия практически невозможные.

Их только две: var и :=. Вторая внутри for (а так же if и switch) ничем не отличается от использования вне этих конструкций.

это будет много ошибок?

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

Забылся, шифт не отжал и получи косяк.

Чушь. Если шифт не нажал где нужно — не будет доступа снаружи к нужному идентификатору, это невозможно не заметить поскольку это помешает реализовать функционал, ради которого идентификатор задумывался экспортируемым. Если шифт нажал где ненужно (гораздо более частый случай) — линтер потребует написать документацию, потому что это обязательно для публичного интерфейса, так что эта ошибка проживёт до первого запуска линтера (т.е. до ближайшего коммита). И, в конце концов, звёздочку в конце имени можно ровно так же забыть или добавить лишнюю.

Была заявка на модульность, а получилось как-то не очень.

Вообще-то нет. Заявку на модульность делают только сейчас, в vgo. До этого заявка была только на пакеты, т.е. по сути на namespace — это нужно для модульности, но это не она.

А в чём проблема допустить атаку по времени? Необходимости держать в секрете файл с базой KeePass нет. При использовании надёжного мастер-пароля этот файл можно взламывать до конца жизни.

Форма объявления с присвоением в голанге — целых ТРИ!

Кто третья?

Но на сколько iota реально востребована?

Вполне востребована и выполняет свою функцию: уменьшает количество ошибок, которые были бы при ручном объявлении перечислений.

Но встретить просто return без возвращаемого значения в голанге…

Да, на мой взгляд это лишняя фича.

В голанге нужно явно получать адрес переменной при передаче по ссылке.

Далеко не во всех случаях, в большинстве случаев компилятор это делает сам, а где не делает — на то обычно есть причина.

В голанге понятие пакета сделано странно.
Экспорт в голанге большой буквы, и сокрытие с маленькой — ну это какая-то фигня.

Вкусовщина.

USB-девайсы для паролей не новость, хоть самодельные, хоть покупные. Но пока этот девайс подключен к компу с той самой OS (и даже не обязательно проприетарной) общего назначения с тьмой софта, работающей на железе с ME — отличия от KeePass совершенно непринципиальные. Чтобы пароль ввести в формочке в браузере его надо как-то в этот браузер передать, и если OS скомпрометирована или ME любопытствует — они что из KeePass что из USB его получат в момент передачи.

Вариант когда USB девайс пароли не передаёт вообще, а работает по схеме уникальный запрос/ответ будет понадёжнее, но на 99.999% сайтов/сервисов такой способ логиниться всё-равно не поддерживается, так что смысла на это заморачиваться пока что нет.

На данный момент комбинация KeePass на компе плюс 2FA через OTP приложение на телефоне — самый надёжный, и даже поддерживается многими сайтами.

Да! А такая есть? :)

Сервер для хранения — не самый критичный момент, особенно если то, что на нём хранится, было зашифровано на клиенте ключом, известным только самому клиенту. Как в случае с хранением базы KeePass в Dropbox или зашифрованных бэкапов в любом публичном облаке.

Совсем другое дело, когда клиентом является, по сути, сторонний веб-сервис вроде LastPass. Сегодня он присылает в браузер надёжный код, который всё шифрует в браузере и передаёт на сервера LastPass только зашифрованные данные без ключа дешифрования… а что он пришлёт завтра?

И никакой опенсорс здесь уже не спасёт, потому что никто не знает, что на самом деле запущено на серверах LastPass. Чтобы такой сервис стал безопасен необходимо скачивать его в исходниках и запускать на своём сервере — а это гораздо больше мороки, чем использовать локальное приложение вроде KeePass.

Да без разницы — как вообще можно доверять свои пароли стороннему сервису? Единственный надёжный вариант — это опенсорсное приложение, полностью работающее на вашем компе, например KeePass. А для доступа с разных устройств БД этого приложения (зашифрованную, само собой), можно синхронизировать через что угодно, даже Dropbox.

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

Meet не работает в этом браузере
Как присоединиться к видеовстрече
Установите последнюю версию Google Chrome

У меня последний Vivaldi, практически хром. О, кстати, есть же хромиум…

С этим аккаунтом нельзя начинать встречи

По ссылке штатная справка на разные темы, понять чего он хочет сходу не вышло.

Мессенджер, который хочет, чтобы им пользовались, не должен так себя вести при попытке с ним познакомится. Кстати о знакомстве — под этим meet скрывается обычный hangouts, или что-то иное?

Мне несколько месяцев назад один любитель продуктов Atlassian скинул ссылочку на Stride. Я не знал что это и чьё это, открыл, посмотрел что походу очередной слак, но потом меня как-то начали смущать знакомые элементы в дизайне, я заподозрил что это дело рук Atlassian, и отмотал страницу вверх чтобы посмотреть логотип… и точно! А следом за лого там идёт пункт меню How It Works — у меня в этот момент в голове сам собой прозвучал напрашивающийся ответ: "меееедлеееннооо!". :)

Что до увеличения задержек в принципе:

• google.com, VPN 45ms, напрямую 42ms
• ya.ru, VPN 75ms, напрямую … ой, забыл что его у нас блокируют.
• habr.com, VPN 58ms, напрямую 11ms (вау, 4 хопа!)
• github.com, VPN 123ms, напрямую 131ms (das ist fantastisch!)

Единственный момент — без VPN задержки более стабильные, а с VPN задержка колеблется в каких-то пределах, не критично, но тем не менее. Но в целом — это вообще не проблема, до тех пор пока речь не заходит о доступе к игровому серверу, находящемуся в своём городе, через VPN в другой стране.

Э… а зачем брать VPN в США? Что до излишней фрагментации, то это надо ещё постараться так сеть настроить — по-моему в наши дни с настройками MTU по умолчанию место для заголовков туннеля обычно оставляют все, но могу ошибаться. В общем, обе проблемы сначала надо себе самостоятельно создать, и только потом получится от них пострадать всласть.

Это вариант чёрного списка. Мне больше нравится вариант белого списка — он проще и очевиднее. У меня есть белый список того, что идёт в инет напрямую:

• торренты (из-за трафика, которым не хочется грузить vpn)
• i2p (по приколу)
• ssh (чтобы уменьшить задержки, если бы игрался — здесь были бы игровые сервера)
• smtp (домашний почтовик дело принципа, не смотря на все препятствия)
• сайт провайдера (иногда они пускают в личный кабинет только из своей сети)
• собственно, сам vpn сервер

Всё остальное идёт через vpn. Отныне, и навеки веков. Аминь.

Самое смешное, что в моём случае дело даже не в РКН — у нас зачем-то решили заблокировать Яндекс. А бегать за ними и перенастраивать каждый раз как они решат ещё что-то поломать в интернете — нет, спасибо. Если им надоело просматривать мой трафик, могли так и сказать — зачем толсто намекать блокировками? В России, конечно, забавнее — одновременно вводят сохранение всего трафика страны на пол года, и тут же переводят большую часть населения на VPN. Умом, как обычно, не понять.

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

Если эта структура — god object, который хранит все данные приложения — то да. Не надо так делать. А если таких структур куча (и у каждой своя горутина-менеджер) — то нет, не превратится в однопоточное.

Насчёт RWMutex Вы правы, он позволит распараллелить доступ. Но обычный Mutex точно так же выстроит всех в одну очередь, как и горутина-менеджер.

В общем и целом статья отличная! Немного комментариев:

так что без проблем можно иметь сотни, и даже тысячи горутин

Mиллионы. От миллиона кое-какие проблемы уже начинаются, но они, по большей части, связаны не с горутинами, а с тем, что обычно в каждой по сетевому соединению, и вот миллионы сетевых соединений ядро без дополнительной настройки уже тянет не очень хорошо.

Go игнорирует достижения современного проектирования языков

Не все йогурты одинаково полезны. Суть описана верно, но я не согласен с тем, что это попадает в категорию "плохой" — я к этому отношусь нейтрально. Да, у них своё — но оно работает, работает достаточно хорошо, и находится достаточно под капотом, чтобы я об этом не задумывался.

Трудно понять, какие типы реализуют конкретный интерфейс

Если честно, я тоже считал это проблемой — когда начинал работать с Go, и ещё плохо ориентировался в типовых интерфейсах и их доступных реализациях. Но через несколько дней я перестал считать это реальной проблемой, и за прошедшие годы ничего не изменилось. Ну а если реально нужно — есть утилиты, которые выдают список таких типов для заданного интерфейса.

Чтобы избежать такой ситуации, рекомендуется использовать маленькие
интерфейсы с очень небольшим количеством методов.

Не думаю, что это с целью чего-то избежать. Это просто идеологически правильно — код должен требовать только тот интерфейс у входных данных, которым он реально пользуется.

Синтаксис := позволяет случайно «затенить» переменную.

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

Так что исключения в Go есть, он использует их внутри себя, но вам не разрешает.

Чушь (может просто перевод не очень удачный?). Исключения для обработки ошибок рекомендуется использовать исключительно внутри своего пакета, как в вышеупомянутом json — чтобы на тех, кто просто использует ваш пакет, это никак не отражалось и в их код случайные паники не вылетали.

Кошмар управления зависимостями

С появлением vgo есть веские основания надеяться, что через год (когда vgo станет официальным go) этой проблемы уже не будет. Причём не просто не будет, а всё будет работать лучше, чем сейчас в других языках!

Похоже, Вы просто не понимаете суть подхода. Структура хранится в одной горутине — выделенном "менеджере" этой структуры. А все остальные горутины получают доступ к ней общаясь по каналам с горутиной-менеджером. Ничего копировать и синхронизировать не нужно. Единственная ситуация, в которой этот подход не очень хорошо работает — когда жёстко не хватает производительности, и замена каналов на один (или группу) мьютексов позволяет заметно всё ускорить.

Библиотека в целом отличная. Да, там есть проблемы, как упомянутые Вами так и другие, и да, если бы вся библиотека была написана исключительно гениями из альфа-центавра, не допустившими ни одной ошибки проектирования в её коде — было бы лучше. К несчастью для нас — её писали люди. Тем не менее, в среднем код стандартной библиотеки заметно лучше среднего, намного лучше поддерживается (исключая не очень удачные пакеты, от которых решили отказаться — вроде net/rpc), и очень помогает то, что весь этот функционал в принципе есть из коробки.

Флаг легко расширять своими типами, и это довольно востребовано. Плюс help для каждого флага занимает много места, и внутри тегов это бы смотрелось не очень. Я думаю, основная причина почему флаг не использует теги, и многих других различий — на этой библиотеке много экспериментировали и пробовали разные подходы, и это заметно.

Тестовый фреймворк отличный. И свою задачу он выполнил — отсутствие assert-ов стимулировало попробовать писать тесты в табличном стиле, и помогло оценить этот подход. А потом assert-ы элементарно добавляются поверх, например: https://godoc.org/github.com/powerman/check

Всё несколько глубже. Вот более-менее полный список нюансов про := и var.

Факты:

• явно указать тип можно только в var
• наглядно сгруппировать (в скобках, с выравниванием) несколько переменных можно только в var
• создать глобальные переменные может только var
• создать переменные локальные для if, for, switch может только :=
• задать смесь новых и существующих можно только в :=
  
  • использование := в этом случае избавляет от лишних строк объявляющих
    переменные да ещё и с обязательным указанием типа (что не всегда
    возможно — в переменной может хранится значение не экспортируемого
    типа возвращаемое некоторыми конструкторами)

Выводы:

• var более функционален для объявления новых переменных
• var более нагляден для объявления новых переменных
• var защитит от случайного изменения существующих переменных вместо объявления новых (go vet -shadow, go-nyet и т.п. могут детектить shadowing, что может снять претензию к := — а плюс в том, что не нужно заранее объявлять и указывать тип)

И пара цитат из книжки Кернигана:

• var name type или var := value в зависимости от важности инициализации начальным значением.
• if err := ...; err != nil {} для уменьшения области видимости err.

… и конфиденциальность закончится на выходе из туннеля.

Если известен IP юзера и IP сайта, то конфиденциальности уже нет — без SNI на данном IP может быть ровно один сайт, так что достаточно скачать его сертификат и там будет его имя (ну или через reverse DNS посмотреть), а со SNI имя сайта необходимо передать до того, как можно будет установить надёжное шифрование, а значит MitM всегда сможет его перехватить, даже если бы его пытались шифровать (это в ответ на коммент Garrett выше насчёт QUIC/SPDY — вряд ли там это смогли решить, это не проблема конкретного протокола).

Хотите конфиденциальности — I2P или Tor, там крайне сложно связать IP юзера и IP сайта.

А что касается DNS — его шифровать бессмысленно, по вышеописанным причинам. А вот обеспечить защиту от поддельных ответов — стоит.

Спасибо, но у меня KeePassXC (не уверен, что он совместим по плагинам с KeePass) и Linux (из https://sourceforge.net/projects/webautotype/files/v5.2.2/: "It uses IAccessible screen assistive technology to 'read' the browser window, and is therefore at this time only supported on Windows.").