Из Facebook

Sep. 26th, 2017 05:16 am
[syndicated profile] gornal_feed
Американский #стартапдня pro.com при запуске напоминал наш profi.ru – даже домен выбрал похожий. Механика взаимодействия пользователя и профессионала не копировала точно российский аналог, но суть была такой же: маркетплейс услуг, проверенные мастера, комиссия как процент суммы сделки. Важное отличие было в том, что pro.com не претендовал на все возможные работы, а ограничился самым большим из сервисных рынков, ремонтом домов и квартир. Проект в таком виде не полетел. О причинах можно долго рассуждать, сам стартап заявляет, что из-за некачественных исполнителей на рынке: “мы, классная IT-компания, прекрасно подобрали сантехника, а тот приехал поздно, работал плохо и испортил почему-то наш имидж, а не свой” – хотя, казалось бы, подбирать надо лучше и проблемы не будет. Вывод из неудачи основатели сделали такой: “раз уж даже самые лучшие ремонтники работают плохо, то не надо делать IT-маркетплейс, а надо делать хорошую ремонтную компанию”. Сказано-сделано, pro.com получил все нужные лицензии (да-да, в США это нужно), на какие-то специальности нанял сотрудников, на какие-то подобрал партнеров и начал ремонтировать дома клиентов сам. Чтобы объяснить инвесторам, зачем класть деньги в ещё одну такую компанию, а журналистам – зачем о ней писать, стартап рассказывает о мобильном приложении для управления персоналом и Умных Алгоритмах определения цены работ. О двух своих реальных преимуществах перед обычной компанией из трех или даже трехсот электриков pro.com молчит, а они, кажется, важнее. Во-первых, деньги сами по себе дают перевес объекту инвестиций: можно агрессивнее расти, меньше думать о текущей прибыльности, больше о будущем. На некоторых конкурентных рынках не так важно в кого вкладывать деньги, тот в кого вложат – тот и станет победителем. Во-вторых, основатели из мира интернета просто сильнее в маркетинге, и в новой модели они используют это по максимуму. Если раньше они привлекали пользователя и продавали его за комиссию, то теперь забирают себе всю маржу, а не часть. За всё, конечно, приходится платить, масштабировать оффлайн-компанию сложнее, чем прописывать новые названия городов в базе данных. Сейчас pro.com работает только в Сиэттле, там уже занимает несколько процентов рынка, и это, безусловно, успех. Недавно стартап получил первый в новой модели раунд инвестиций, 10 миллионов долларов, и обещает открыть по городу на каждый миллион.

Comic for September 26, 2017

Sep. 26th, 2017 11:59 pm
[syndicated profile] dilbert_feed
Dilbert readers - Please visit Dilbert.com to read this feature. Due to changes with our feeds, we are now making this RSS feed a link to Dilbert.com.
[syndicated profile] gorynych1_feed
Поскольку, как тут уже говорилось, именно ветроэнергетика, в ближайшей перспективе, даст возможность прироста значительных объемов дополнительной дешевой генерации, необходимой для перехода человечества в постиндустриал, - то вопросы ее развития привлекают наиболее пристальное внимание.


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



http://ieefa.org/ieefa-europe-technology-gains-help-drive-rush-capital-markets-offshore-wind/

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



https://twitter.com/energy_charts

Кстати, в одном из передовиков "ветрового фронта" Дании подсчитали, что если заменить все имеющиеся в Дании возрастные турбины на современные, то их понадобится ровно в два раза меньше для производства того же количества энергии.

Не все так просто.

Хотя, как говорится, на халяву и уксус сладкий, у ветровой генерации существует одна неприятная особенность.
Так называемая нерегулярность генерации.
Для примера можно посмотреть на эту картинку.



https://twitter.com/energy_charts

И речь тут идет вовсе НЕ о суточной "пиле".
Днем потребление растет, ночью и по выходным падает - с такой "пилой" электроэнергетика существует с самого начала ее существования, и никогда это особых проблем не вызывало.

Речь идет о отдельных "всплесках" особо ветряной погоды, когда электроэнергии от ветра становится слишком много.
На картинке это отчетливо видно - сравните объемы ветрогенерации в начале и в конце недели.
И возникает вопрос - если строить еще дополнительные объемы, то в отдельные дни или недели, "мусорной" электроэнергии будет просто дикое количество, которое, в худшем случае, грозит просто обрушить энергосистему, а в лучшем случае эта дармовая энергия просто будет терятся без всякой пользы.

Как из лимона сделать лимонад.

Грубо говоря, постиндустриальная энергетика точно также кардинально отличается от индустриальной энергетики, как и вообще все в постиндустриале по сравнению с индустриалом...
Если в индустриале проблема неравномерности потребления решалась за счет генерации, т.е. за счет строительства дорогих избыточных мощностей с плохим КИУМ, и особенно дорогих "пиковых" газовых, закрывающих собой всплески потребления вечернего и утреннего пиков.
То в постиндустриальной энергетике проблема неравномерности генерации будет решаеться за счет умного потребления.
Smart-grid - это система, в которой потребитель добровольно-принудительно отказывается потреблять электричество в период нехватки дешевой генерации, и смещает потребление на период избытка дешевой генерации.

Самый простой пример - холодильник может вполне подождать пару часов, пока пройдет вечерний пик, и морозить ранее и позднее этого дорогого пика. А если не подождет, то его хозяину придет счет, космических размеров. :)
Холодильник такой уже есть, например этот:
https://www.digitaltrends.com/refrigerator-reviews/lg-instaview-lfxc24796s-review/
(Кстати, этот момент, в том числе, упоминался ранее, когда говорилось, что холодильник без интернета по итогу будет стоить гораздо дороже, чем холодильник с интернетом) :)

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

Однако все равно остается вопрос - что делать, когда "мусорной" электроэнергии полно в более долговременном срезе. Несколько недель, месяц, вплоть до сезонного, когда, грубо говоря, летом ветра - мало, а зимой много - это стандартный не только для Европы pattern.
И хотя идут эксперименты по использованию самых разных подходов - от сезонных накопителей до "умного" двойного отопления газ-электричество..., от строительства ГАЭС в старых шахтах до синтеза водорода - все это, на мой взгляд, решением не является.

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

И решение лежит в наличии другого лимона, из которого тоже требуется сделать лимонад.

А именно - пост-индустрии.

Дальше едешь - шЫре морда.

Об этом тут уже говорилось, и весьма много.
Уже тестируются в лабораториях, и в ближайшее время, в ближайшие годы, как минимум в нескольких видах производства, на рынок выйдут 3d принтеры, обеспечивающие МАССОВОЕ производство продукции, как минимум не дороже, чем традиционное производство...
Именно за счет экономии на трех основных китах постиндустриала - дорогой рабочей силе, дорогих ресурсах, и дорогой экологии.
И как мы понимаем, эта вилка будет расти, из-за дальнейшего удорожания традиционного производства.

Там где раньше токарь Вася за зарплату в три копейки мог выточить втулку, отправив половину заготовки в отходы, и положив эту втулку на полгода на склад, и потом отправив ее покупателю через полпланеты... будет стоять принтер, печатающий все прямо на месте и on demand. С огромной экономией на всех вышеперечисленных нюансах.

Единственная, портящая экономику деталь - 3d печать весьма энергоемка.
Ибо вместо дяди Васи стоит лазер.
И это определенная проблема, верно?
Верно.
Но если ее скрестить с вышеуказанной проблемой избытка "мусорной" генерации, то обе эти проблемы взаимоуничтожаются.
Населению раздавать энергию на халяву - нельзя. Ибо доказано, что не в коня корм.
Вместо этого, выданное на халяву электричество, в периоды его избытка, будет замечательно скушано автоматическими фабриками и цехами 3d-печати, повышая их общую (по году) рентабельность. Производственный процесс будет изначально проектироваться на работу с большей нагрузкой, в периоды сезонного переизбытка, и тем более, не побрезгует отдельными пиками выработки э/э в течении года.
С вариантом полной остановки в периоды ветрового штиля. Это вообще не проблема - фабрики работают без людей, когда нужно 24 часа в сутки и 7 дней в неделю, и при прерывании производственного процесса не нужно продолжать платить зарплату.
Или, другими словами, как в анекдоте, когда ветер дует, тогда кокосы едим, а когда не дует - значит неурожай.

Или другими словами, чем больше ветрогенерации - тем более конкурентоспособно промышленное производство.

P.S. Ну а оставшееся можно загонять в водород.
Или ананасы в теплицах выращивать. :)

Все только начинается.(c)
vlkamov: Рембрандт. Автопортрет с широко открытыми глазами. (Default)
[personal profile] vlkamov
- Сколько нужно политиков, чтобы заменить лампочку в туалете?
- Два: пока один пытается вкрутить лампочку в трубу для душа, второй объясняет, что делается всё возможное.

Невинодел возмущен
Фальшивобутыльщики
Они там еб@нулись на всю голову. Закон о маркировке стеклянных бутылок примут до конца года

Производителям меченной тары с «палёной» водкой внутри грозят миллионные штрафы и до 8 лет лишения свободы.

В принципе, если подумать, индивидуальная маркировка бутылок необходима для прекращения выпуска спиртного контрафакта. И это было очевидно еще при первом взлете производства паленки, роялей и т.п. Тогда я не слышал ничего про блокчейн, полагал, что достаточно более-менее защищенных баз данных у государства.

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

Особенно следует отметить, что инд.маркировка бутылок делает акцизные марки абсолютно излишними. Более того, марки с самого начала были излишними и внедрялись по платонно-ротенберговской схеме, чтобы нужные люди, силовики посидели на денежных потоках. Коррупция и уродство - вот что это такое. Они измываются над потребителем и еще берут с него за это деньги - тройное удовольствие. Да и потешиться над производителем тоже доставляет - приятно глядеть как дяденьки и тетеньки выгибаются в нервничают в попытках присобачить это уродство к готовому изделию. "Конструкция" акцизной марки выдает, что инженерами здесь и не пахло, это творчество "товарища майора" с одной извилиной.

Такого удовольствия лишаться никак нельзя, поэтому маркировка будет несколько более другая
По его словам, самый простой способ идентификации — это законодательно обязать производителей стеклотары маркировать свою продукцию.

«Тогда любой потребитель сможет перевернуть бутылку, посмотреть на донышко и увидеть, что она была изготовлена, к примеру, на Липецком или Владимирском стекольном заводе. Для этого у каждого предприятия должна быть индивидуальная маркировка», — отметил сенатор.

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

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

На днях "больной цифровой экономикой" спросил у яндексов: "Когда робот заменит человека ?". Как они мялись, чтобы не сказать "только через твой труп" - коровник колхоза имени ХХ-го партсъезда затаил дыхание, наслаждаясь мычанием двуногих телков. Ведь кремлевская камарилья живьем не откажется повластвовать всласть, а какая сласть от робота ? Он тупо выполнит команду либо сломается.
vlkamov: Рембрандт. Автопортрет с широко открытыми глазами. (Default)
[personal profile] vlkamov
Оригинал взят у [profile] solar_front в тут понимать надо: Четвертый срок Меркель и Путина - это не одно и то же...
"Четвертый срок Меркель и Путина - это не одно и то же"


"- Здесь есть большая разница. При победе на выборах партии Меркель (имеется в виду блок партий ХДС/ХСС, кандидатом в канцлеры от которого выступает Ангела Меркель - Ред.) она сможет сформировать правительство только при наличии коалиции - а значит, ей придется идти на компромиссы. Путину же нет необходимости идти на компромиссы, ведь депутаты в Госдуме всегда поддерживают все идеи президентской администрации. Понятно, что в России фактически нет оппозиции, а у Меркель она есть."

Гражданин "забывает", что Канцлер не выбирается в ФРГ народом, но президент России - да. Поэтому ему и "коалиция" не особо нужна.


И интеллектуальная мощь немецкого политика:
"У либералов было гораздо меньше средств, чем у других. Поэтому они сделали ставку на интересные и смешные идеи. "

п.с. Вообще это праздник какой-то: всё пропогандисткое говнище решило враз вылится онлайн.

Ни дня без няши.469

Sep. 26th, 2017 08:04 am
laan: (Кровь богу крови!)
[personal profile] laan
CRf2x_QGLw_Js

Read more... )

ЦБ задел Дерипаску?

Sep. 25th, 2017 10:40 pm
[syndicated profile] ecworld_feed
Папа уже помогал ранее. Теперь посмотрим, как будет вести себя мама.

Конечно, все понимают, что история с Открытием и Бинбанком только начинается: схемы только будут раскручивать, а дыры, которые дополнительно и случайно возникнут (см. запись в нашем канале Telegram от 22 сентября 2017 года, 20:30), придется как-то объяснять и закрывать. И наивно полагать, что:

... вряд ли нынешний акционер сможет предъявить требования к страховщику о признании страхового случая в связи с покупкой «Росгосстраха» и санации банка «Траст», так как обе эти сделки были непосредственно согласованы с самим Банком России (с) http://www.rbc.ru/finances/25/09/2017/59c935b19a79475337e75bdd

Ведь, когда (если) раскрутят (или ЦБ будет управлять всей это махиной?*) обратно схему с недвигой и еще рядом активов и по сделкам с ними будет получен убыток (если "китайцы" снова не выкупят по правильной цене), то, скорее всего, предыдущие действия акционеров попадут как раз под страховой случай - и убыток может быть больше, чем все страховые сборы Ингосстраха за последний год:

Ответственность руководства «ФК Открытие» была застрахована в «Ингосстрахе». Выплата по этому договору может стать крупнейшей в истории, говорят эксперты. Впрочем, страховщик уже заявил, что не признает санацию страховым случаем (с) http://www.rbc.ru/finances/25/09/2017/59c935b19a79475337e75bdd

* я вот думаю, не пора ли ЦБ (по аналогии с ФКБС) создать ФКН (фонд консолидации недвижимости)? Скажем, на базе компаний, занимающихся недвижимостью, являющихся лидерами этого рынка и кредитующихся в Сбербанке? В общем, отдайте всё Сбербанку в управление: недвижку Открытия, Бина, Югры ...  на пару трлн рублей. Ведь, нам мало надувного в акциях Сбера, возникшего на фоне уничтожения частного банковского сектора. Пора уже и недвижимости в цене расти.

_
Если Вы хотите понимать, что происходит вокруг Вас, а также получать больше полезной информации и получать ее более оперативно, поставьте приложение Telegram и присоединяйтесь к нашему новому каналу - http://t.me/ecworld - заходите и обязательно нажимайте внизу канала кнопку JOIN.

hollymath: (Default)
[personal profile] hollymath
Andrew has (extremely carefully and only after I said it was okay, having learned from last week's debacle!) opened the post from the Home Office and can confirm that it's my UK passport.

I'm not even happy or relieved yet. I'm so ground-down by the whole process that it still hasn't sunk in yet, even as I look at it with the lettering all shiny, next to me on the table, waiting to be taken upstairs and filed away into unobtrusive normality.
fizzik: (Default)
[personal profile] fizzik
Михалков собрался открывать барбершоп "Сибирский цирюльник".

Интересно, а чем закончилась его прошлое начинание по открытию сети посконно-скрепных ресторанов русской кухни, которая должна была вытеснить культурно и классово чуждый "Макдональдс"?
[syndicated profile] ecworld_feed
Раз, у нас сегодня тут вечер юмора, то почему бы нам не пофантазировать о прекрасном будущем вместе с аппаратом правительства.

Глядя на сегодняшний 4%-ый рост нефти с выходом на значения середины 2015 года, и начало отрисовки технической перевернутой фигуры "голова-плечи", почему бы нам не помечnать о предстоящем ралли в нефти до 115 долларов за баррель к Выборам Президента РФ.

Ведь, столько позитивного стало происходить: и инфляция рекордно низкая за всю историю современной России, и безработицу победили, и экономика рост показала, и у россиян растет показатель "счастья" ...  нам вот только нефти не хватает на исторических хаях, чтобы все вместе в едином порыве придти на Выборы и ...  поддержать путь разивития страны, путь улучшений и побед:

[syndicated profile] ecworld_feed
Перед тем, как робот-пристав автоматически спишет штраф с вашей зарплатной карты МИР, единственно работающей платежной системы в России, в единственно работающем Банке страны, - вам сначала его искусственно начислят (возможно, с использованием систем искусственного интеллекта):

Жительнице Москвы Анне Назаровой выписали штрафы за неправильную парковку на 320 тыс. руб. По словам женщины, нарушения были зафиксированы в районе Дорогомилово, где Назарова проживает с 2015 года. Тогда она через центр госуслуг оформила резидентное соглашение на парковку, а в апреле 2016 года переоформила его на портале mos.ru. В мае 2016 года она оплатила несколько мелких штрафов на этом портале.

В декабре 2016 года Назарова обнаружила на портале штрафы на сумму 320 тыс. руб., первый из которых был датирован маем 2016 года. В главном контрольном управлении «Администратор московского парковочного пространства» («Московский паркинг») Назаровой сообщили, что она оплатила резидентное соглашение за 2015–2016, а не за 2016–2017 годы. «
Некоторые по второму, по третьему разу платят», — заявили в управлении. Назаровой не смогли объяснить, почему данные о штрафах не появлялись на портале, добавив, что в мае 2016 года на сайте произошел сбой (с) http://www.rbc.ru/rbcfreenews/59c93e389a794756a4f8364c


Похоже, это становится нормальным кидать граждан в стиле 90-ых: это был не второй платеж по кредиту, это ты первый платеж, просто, повторно оплатил, так бывает, теперь заплати второй платеж.

Конечно, суд разберется. Возможно, женщина и виновата, но в последнее время слово прецедент всплывает всё чаще в негативном поведении государственных "мужей" (ссылка 1, ссылка 2).

и они нас "ведут":

Sep. 25th, 2017 07:11 pm
[syndicated profile] ecworld_feed
Руководитель крупнейшей компании финансового сектора страны назвал алгоритмы скоринга, написанные человеком, - искусственным интеллектом:

«Не меньше $2 млрд в год чистой прибыли мы зарабатываем за счет того, что внедрили своевременно модели, построенные на системах искусственного интеллекта», — сказал Греф (с) http://www.rbc.ru/rbcfreenews/59c94bbb9a79476281937af5

Его и раньше (еще со времен МЭРТ) можно было не слушать, но в этом году развитие "личной ситуации" у человека идет ускоренными темпами. Одно, второе, третье ...  И тут вдруг человек изобрел первым в мире искусственный интеллект.

P.S. Теперь понятно, кто скупает акции Сбербанка. Искусственный интеллект. И никто ничего с этим поделать не может. Он просто выбирает каждый второй рубль из приходящих во вклады и покупает на них акции. Каждую секунду. И серваки пытались отрубить, и электричество во всем центральном офисе и дата-центрах отключали ...   ничто не помогает, копирует себя по блокчейн-сети и всё, наперед определяя действия сотрудников на основе agile и bigdata.

redtigra: (Default)
[personal profile] redtigra
У пилота есть парашют - это хорошо.
Парашют не раскрылся - это плохо.


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

Пилот падает на стог сена - это хорошо.
Из стога сена торчат вилы - это плохо.
Эйчар мне и говорит: фиг тебе, а не. У нас хайринг фриз.

Я объясняюсь знаками, из которых ни одного цензурного. Иду по верхам, скандалю. У меня три позиции открыто, хрен с остальными, но вот же уже человек!

Приходит эйчар и спрашивает - ты ему письмо послала? Послала, говорю. Тогда давай, делаем. В пятницу послали офер.

На вилы, то есть, я не попал. Это хорошо.

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

В стог сена, то есть, мы тоже не попали. Это плохо.

Ну что. Сказала матом, закрыла лавочку, фриз твердый, не объедешь, не пророешь. Сиди, дорогой тигр, без трех. Дословно. Три позиции открыты.

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

Принял, говорит, я ваш офер и подписанный контракт уже отослал. Та компания, которая меня так хотела... и я в общем тоже туда хотел...

Короче, у них хайринг фриз.

What should follow the web?

Sep. 25th, 2017 07:13 pm
[syndicated profile] mikehearn_feed

Posted by Mike Hearn

Design principles and an instantiation for a post webapp world

In part 1 of this series I argued that it’s time to start thinking about how to replace the web. The justifications are poor productivity and unfixable security problems.

Some people felt that what I wrote was too negative, and didn’t recognise the web’s good points. That’s right: part one was “let’s discuss the idea that we’ve dug ourselves a big hole”, part two is “how do we design something better?” This is a huge topic so it will actually take more than two parts.

Let’s call our competitor to the web, NewWeb (er, branding can come later). To start we must understand why the web became successful in the first place. The web out-competed other ways of writing apps that had far better tools for building graphical applications, so clearly it had some qualities that overwhelmed its flaws. If we can’t match those we’re doomed.

We also need to focus on cheapness. The web has vast teams of full time developers building it. Much of their work is duplicated or thrown away, some of what they’ve created can be reused, and small amounts of new development might be possible … but by and large any NewWeb will have to be assembled out of bits of software that already exist. Beggars can’t be choosers.

Here’s my personal list of the best 5 things about the web:

  1. Deployment & sandboxing
  2. Shallow learning curve for users and developers
  3. Eliminates the document / app dichotomy
  4. Advanced styling and branding
  5. Open source and free to use

These aren’t exactly the most famous design principles: if you asked most developers to sum up the essence of the web’s architecture they’d probably say URLs, view source, cross platform, HTTP and so on. But those are just implementation details. The web didn’t take over from Delphi and Visual Basic because JavaScript rocked so much more. There were deeper reasons.

The above things are pretty self explanatory. I’ll analyse them more as we go. To beat the web we must go further than just matching what it does well, we must also offer unique improvements the web cannot easily incorporate. Otherwise there’d be no point: we’d just work on making the web better instead.

I offer two things in this text: some design principles I think any serious web competitor should follow, and a concrete instantiation cobbled together out of various open source projects. Many readers won’t like that concrete instantiation because they’ll have other projects or languages in mind they like better, and that’s fine. I don’t care. It’s just an illustration — really it’s the principles that matter. I name specific codebases only to show that dreaming is not totally unrealistic.

Design principles

The web lacks a coherent design philosophy, at least for the app parts. Here’s some things I think it should have but lacks:

  1. A clear notion of app identity
  2. A unified data representation from backend to frontend
  3. Binary protocols and APIs
  4. Platform level user authentication
  5. IDE oriented development
  6. Components, modules and a great UI layout system — just like regular desktop or mobile development.
  7. It will also need the things the web does well: instant start of streaming apps with no installation or manual updates required, sandboxing of those apps, sophisticated UI styling, mix and match of “documenty” stuff with “appy” stuff (like being able to link to particular app views), a very incremental learning curve and a design that discourages developers from building UI that is too complicated.

The first four items in bold are all security related. That’s because security issues are my motivation for taking such an extreme position. Perhaps the low productivity of the web could be fixed with yet another JavaScript framework — perhaps. But I don’t think security can. I’ll look the non-bold items in later parts.

App identity and linking

To get the deployment and sandboxing benefits of the web, some sort of app browser will be required. We’d also like the ability to treat parts of an app as if it were a hypertext document so we can link to things. That’s a key part of the web’s success — an Amazon search results page is sort of an app, but because we can link to it, it’s also sort of a document.

But our app browser shouldn’t physically resemble a web browser. Look at it with fresh eyes: web browser UI is not excellent.

The URL is a key part of the web’s design but it does make a mess sometimes!

The first problem is that URLs leak all over the UI. The URL bar routinely holds random bits of browser memory encoded in a form that is difficult to understand for both humans and machines, leading to a parade of exploits. If a desktop app dumped random internal variables into the title bar we would rightly regard that as brand-destroying bugginess, so why do we tolerate it here?

The second problem is that URLs are hard to read for machines too (mind blowing exploits available here). Even ignoring clever encoding tricks like those, the web has various ways to establish the identity of an app. Browsers need some notion of app identity for separating cookie jars and tracking granted permissions. This is an “origin”. The concept of a web origin evolved over time and is essentially impossible to describe. RFC 6454 tries, but as it admits:

Over time, a number of technologies have converged on the web origin concept as a convenient unit of isolation. However, many technologies in use today, such as cookies [RFC6265], pre-date the modern web origin concept. These technologies often have different isolation units, leading to vulnerabilities.

For example, ponder what stops your server setting a cookie on the .com domain. Now what about kamagaya.chiba.jp? (it’s not a website, it’s a section of the hierarchy like .com is!)

Being able to unexpectedly link to parts of an app that don’t benefit from it and aren’t expecting it is one of the sources of the “dangerous link” problem. Heavily URL-oriented design makes all of your app subject to data injection by malicious third parties, a design constraint that’s proven near impossible to handle well, yet is blithely encouraged by the web’s architecture.

Still, being able to link to the middle of an app from documents and vice-versa is pretty nice when it works and is expected by developers. Let’s take a couple of requirements:

Requirement: app identity (isolation) must be simple and predictable.

Requirement: we must be able to deep link into an app, but not always.

To their credit, the Android designers recognised these requirements and came up with solutions. We can start there:

  • App identity is defined by a public key. All apps signed by the same key share the same isolation domain. String parsing is not used to determine isolation.
  • Apps can opt-in to receiving strongly typed packets of data that that ask them to open themselves with some state. Android calls this concept “intents”. Intents aren’t actually very strongly typed in Android, but they could have been. They can be used for internal navigation as well, but to allow linkage from some other app the intent must be published in the app’s manifest. By default, the app cannot be invoked via links.
  • Where to find an app to download? A domain name is a good enough starting point. Whilst we could support HTTP[S] downloads too, ideally we’ll find a NewWeb server listening on a well known port and we can fetch the code from there. So a domain name becomes a starting point for getting the app, but is otherwise quite unimportant.

To distinguish URLs and intents from our own take, let’s call them link packets.

Requiring developers to opt-in to external linkage will lower the linkability of NewWeb in order to improve its security. Perhaps that is a poor tradeoff and will be fatal. But many links people can theoretically create on the web today are invisibly useless anyway due to authentication requirements, or because they don’t contain any useful state to begin with (many SPAs). And such apps would minimize their surface area for attack. The malicious link that is the starting point of so many exploits would immediately become less severe. That seems valuable.

There are other benefits too — the importance of the domain name for webapps makes it tempting for domain providers to seize domains their executives personally disagree with. Whilst simple websites can be relocated without too much pain, more complex sites that may have established email reputations, OAuth tokens etc are more badly harmed. Private keys can be lost or stolen, but so can domain names. If you lose your private key at least it’s your own fault.

As for the rest of the browser UI, it can probably be scrapped. Tabs could be useful, but reload should never be necessary and the back button can be provided by the app itself when it makes sense to do so, a la iOS.

How to build the app browser? Even though NewWeb is pretty different to the web, the basic UI of fullscreen apps is OK and users will want to switch back and forth. So why not fork Chromium and add a new tab mode?

A unified data representation

Maybe the link packet concept sounded a bit vague. What is this thing? To define it more precisely we need data structures.

The web has a variety of ways to do this but they’re all text based. To stress a point from my last article, text based protocols (not just JSON) have the fundamental flaw that buffer signalling is all ‘in band’, that is, to figure out where a piece of data ends you must read all of it looking for a particular character sequence. Those sequences may be legitimately a part of the data, so that means you also need an escaping mechanism. And then because these protocols are meant to be sorta human readable, or at least nerd readable, there are often odd corner cases to do with whitespace handling or Unicode canonicalisation that end up leading to exploits, like HTTP header splitting attacks.

In the early days this might have helped the web catch on with developers. View source has definitely helped me out more times than I can count. But the average web page is now over 2 megabytes in size, let alone web app. Even boring web pages of static text frequently involve masses of minified JavaScript that you need machine help to even begin to read. The benefits seem less than they once did.

A primitive decompiler

In fairness, the web has in recent years been slowly moving away from text based protocols. HTTP/2 is binary. The much touted “WebAssembly” is a binary way to express code, although it doesn’t actually fix any of the problems I’ve been discussing. But still.

Requirement: data serialisation should be automatic, typed, binary and consistent from data store to front end.

Serialisation code is not only tedious to write but also a major attack surface. A good platform would handle it for you. Let’s define a toy syntax for expressing data structures:

The web equivalent of this would be an amazon.com URL. It defines a immutable typed data structure to represent a request to open the app in some state.

That data structure is marked with @PermazenType. What’s this all about?

If we’re serious about being length prefixed, strongly typed and injection-free throughout the entire stack then we have to do something about SQL. The Structured Query Language is a friendly and well understood way to express sophisticated queries to a variety of stonkingly powerful database engines, so this is a pity. But, SQL is a text based API. Despite SQL injection being one of the easiest exploit types to understand and fix, it’s also one of the most common bugs in real websites. That’s no surprise: the most obvious way to use SQL in a web server will work fine but silently opens you up to being hacked. Parameterised queries help but are a bolt-on fix, which can’t be used in every situation. The tech stack creates a well disguised bear trap for us to fall into and our goal is to minimize the feature:bear ratio.

SQL has some other issues. You quickly hit the object-relational mapping problem. The results of a SQL query can’t be natively sent over an HTTP connection or embedded into a web page, so there’s always some required transformation into another format. SQL hides the performance of the underlying queries from you. The backends are hard to scale. Schema changes often involve taking table locks, making them effectively un-deployable without triggering unacceptable downtime.

NoSQL engines are not convincingly better: they typically fix one or two of these problems but at the cost of throwing out SQL’s solutions to the rest, meaning you’re often stuck with a solution that is different but not necessarily better. As a consequence the biggest companies like Google and Bloomberg have spent a lot of time researching how to make SQL databases scale (F1ComDB2).

Permazen is a new take on data storage that I find quite fascinating at the moment. Quoting the website:

Permazen is a completely different way of looking at persistence programming. Instead of starting from the storage technology side, it starts from the programming language side, asking the simple question, “What are the issues that are inherent to persistence programming, regardless of programming language or database storage technology, and how can they be addressed at the language level in the simplest, most correct, and most language-natural way?”

Permazen is a Java library, however, its design and techniques could be used in any platform or language. It requires a sorted key/value store of the kind that many cloud providers can supply (it can also use an RDBMS as a K/V store), but it does everything else inside the library. It doesn’t have tables or SQL. Instead it:

  • Uses the collection operations of the host language to do unions and intersections (joins).
  • Schemas are defined directly by classes, it does not require an object/relational mapping to be defined.
  • Can do incremental schema evolution ‘just in time’, avoiding the need for table locks to change how data is represented in the data store.
  • Transactions are precisely defined and copying data out of a transaction or back in is clearly controllable by the developer.
  • Change monitoring, such that you can get callbacks when the underlying data changes, including across processes (if the underlying K/V store supports this, which they often do).
  • There’s a CLI that lets you query and work with the data store (e.g. to force data migrations if you don’t want just-in-time migration), and a GUI.

Really, you should just read the excellent white paper or read the slides (the slides use the old name for the library but it’s the same software). Permazen isn’t well known, but it’s the cleverest and slickest approach to integrating data storage tightly with an object oriented language that I’ve yet seen.

One of the interesting things about Permazen is that you can use ‘snapshot transactions’ to serialise and deserialise an object graph. That snapshot even includes indexes, meaning you can stream data into local storage if memory is too small and do indexed queries over it. It should be clear how this can provide a unified form of data storage with offline sync support. Resolving conflicts can be done transactionally as all Permazen operations can be done inside a serialisable transaction (if you want a Google Docs like conflict-free experience that will require an operational transform library).

NewWeb doesn’t have to use this sort of approach. You could use something a bit more traditional like protobufs, but then you need to use a special IDL which is equally inconvenient in all languages, and also tag your fields. You could use CBOR or ASN1. In my current project, Corda, we have built our own object serialisation engine that builds on AMQP/1.0 and in which messages are by default self describing, so given a binary packet you can always get back the schema — as such it can do a View Source feature, kinda like XML or JSON. AMQP is nice because it’s an open standard and the base type system is pretty good (e.g. it knows about dates and annotations).

The point is that receiving data from potentially malicious sources is risky, so you want as few degrees of freedom in the format as possible and as many integrity checks as possible. All buffers should be length prefixed, so users can’t inject malicious data into a field to try and terminate it early. Data needs to be thoroughly checked as it’s loaded, so the best place to do that is in the type system and constructors of the data structures themselves — that way you can’t forget. Schemas help understand what the structure should be, making it harder for attackers to create type confusions.

Despite the fully binary nature of the proposed scheme, a one-way transformation to text can be defined for debugging and learning purposes. In fact, Permazen does that too.

Simplicity and learning curve

One problem with type systems is that they add complexity; they can feel like a lot of pointless bureaucracy to developers who aren’t used to them. And without tooling, binary protocols can be harder to learn and debug.

Requirement: a shallow learning curve

I’m convinced that a big part of the web’s success is because it’s essentially untyped — everything is just strings. Bad for security, productivity and maintainability but really good for the learning curve.

One way this is being addressed in the web world is with gradually typed versions of JavaScript. That’s good and valuable research, but those dialects aren’t widely used and most new languages are at least somewhat strongly typed (Rust, Swift, Go, Kotlin, Ceylon, Idris …).

Another way to address this might be with a clever IDE: if you let developers start out with untyped data structures (everything is defined as Any) the runtime can figure out what the underlying types seem to be, and feed them back into the tool. It can then offer to swap in better type annotations. If the developer seems to be encountering typecast errors as they work, the IDE can offer to relax the constraint back again.

Of course, this gives less safety and maintainability than forcing the developer to really think about things up front, but even fairly weak heuristically determined types that only trigger errors at runtime can protect against a lot of exploits. Runtimes like the JVM and V8 already collect this sort of type information. In Java 9 there’s a new API that lets you control the VM at a low level (the JVMCI) which exposes this sort of profiling data — it’d be a lot easier to experiment with this type of tooling now.

Languages and VMs

Talking of which, what language should NewWeb use? Trick question of course: the platform shouldn’t be fussy.

There have been many attempts to introduce non-JavaScript languages to the web over the years, but they all died trying to get consensus from browser vendors (mostly Mozilla). In fact the web has gone backwards over time in this regard — you used to be able to run Java, ActionScript, VBScript and more, but as browser vendors systematically erased plugins from the platform everything that wasn’t JavaScript got scrubbed out. That’s a shame. It could certainly use competition. It’s a sad indictment of the web platform that WebAssembly is the only effort to add a new web language, and that language is C … which I hope you don’t want to write web apps in! XSS is bad enough without adding double frees on top.

It’s always easier to agree on problems than solutions, but never mind — it’s time to get (more) controversial. The core of my personal NewWeb design would be the JVM. This will not surprise those who know me. Why the JVM?

  • HotSpot can run the largest variety of languages of any virtual machine, and the principle of cheapness dictates that we want to be able to use as much open source code as possible.
    Yes, that means I want to be able to make apps that include JavaScript (run at high speed), along with Ruby, Python, Haskell, and oh yes — C, C++ and Rust should come along for the ride too. All this is possible because of two really cool projects called Graal & Truffle, which I’ve written about extensively before. These projects let the JVM run even languages you wouldn’t expect (like Rust) in a virtualized, fast and interoperable way. I don’t know of any other VM that can blend so many languages together, so seamlessly, and with such good performance.
  • The OpenJDK sandbox has been attacked relentlessly for years and has learned the same painful lessons that web browser makers have. The last zero day exploit was in 2015, and the one before that was in 2013. Just two sandbox 0-days in 5 years is good enough for me, especially because lessons have been learned from each exploit found and fundamental security improvements have been made over time. No sandbox has a perfect track record, so really this boils down to a personal judgement call — what level of security is good enough?
  • There’s huge quantities of high quality libraries that solve key parts of the puzzle, like Permazen and JavaFX.
  • I happen to know it quite well and I like Kotlin, which has a JVM backend.

I expect lots of people to disagree with that choice. No problem — the same design ideas can be implemented on top of Python or V8 or Go or Haskell, or whatever else floats your boat. Best if you can pick something that has an open spec with competing implementations though (the JVM does).

The politics of Oracle don’t concern me much because Java is open source. There aren’t a lot of high quality, high performance open source runtimes out there to choose from. The ones that do exist are all built by giant software firms who have all made their own questionable decisions in the past as well. The web has at various times been heavily influenced or outright controlled by Microsoft, Google, Mozilla and Apple. All of them have done things I found objectionable: that’s the nature of large companies. You won’t agree with their actions all the time. Oracle won’t win any popularity contests, but the nice thing about open source code is that it doesn’t really have to.

There are a few things I’d want to reuse from Google Chrome specifically. My app browser should support an equivalent to WebGL (i.e. eGL), and Chromium’s ANGLE project would be useful for that. The app browser should silently auto update like Chrome does, and Google’s auto update engines are open source too. Finally, whilst the Pack200 format compresses bytecode by a lot, throwing in nice codecs like Zopfli wouldn’t hurt.

RPC

Binary data structures aren’t enough. We need binary protocols too. A standard way to link client with server is RPC.

One of the coolest British startups right now is Improbable, who have published a great blog post on how they’re moving away from REST+JSON and towards gRPC+protobufs from the browser to the server. Improbable describe the result as a “type safe nirvana”. Browsers don’t make this as easy as HTTP+XML or JSON, but with enough JavaScript libraries you can bolt it on top. It’s a good idea. Back in the real world where we’re all writing web apps, you should do this.

RPC protocols take some experience to design. My dream RPC supports:

  • Returning futures (promises) and ReactiveX Observables, so you can stream “push” events naturally.
  • Returning large or infinitely sized byte streams (e.g. for live video).
  • Flow control for high vs low priority transfers.
  • Versioning, interface evolution, type checking.

Again, in the Corda project we’ve tackled designing an RPC stack with these properties. It isn’t currently released as a standalone library but perhaps in future we’ll do that.

HTTP/2 is one of the most recent and most designed parts of the web, and it’s a decent enough framing and transport protocol. But it inherits a lot of cruft from HTTP. Consider the hacks opened up by obscure HTTP methods that are never used. HTTP’s odd approach to state doesn’t help. HTTP itself is stateless, but apps need stateful sessions, so app devs have to add their own on top using a mishmash of easily stealable cookies, tokens and so on. This leads to problems like session fixation attacks.

It’d be better to split things more clearly into layers:

  • Encryption, authentication and session management. TLS does a decent job of this. We’d just reuse it.
  • Transport and flow control. HTTP/2 does this, but messaging protocols like AMQP also do it, without the legacy.
  • RPC

The RPC stack is obviously integrated with the data structure framework, so all transfers are typed. Developers never need to do any parsing by hand. RPC naming is just a simple string comparison. There are no path traversal vulnerabilities as a consequence.

User authentication and sessions

NewWeb would not use cookies. It’s better to use a public/private keypair to identify a session. The web is heading in this direction, but to be compatible with existing web apps there has to be a complicated “binding” step where bearer tokens like cookies are connected to the underlying cryptographic session and that’s just needless complexity in a security sensitive component — it can be tossed in a clean redesign. Sessions are only ever identified on the server side by a public key.

User authentication is one of the hardest bits of a web app to get right. I wrote down some thoughts on that previously so I won’t go deep on that again. Suffice it to say that linking a session to an email address is a feature best handled by the base platform and not constantly re-invented at the app layer. A client side TLS certificate is sufficient to implement a basic single sign-on system, with the basic ‘send email and sign certificate if received’ flow being so cheap that Lets Encrypt style free providers are not unthinkable.

This approach builds on tech that already exists, but should make a serious dent in phishing, password database breaches, password guessing and many other related issues.

Conclusion

A platform that wants to compete with the web should have a strong focus on security, as that’s the primary justification and competitive advantage. It’s the main thing you can’t easily fix about the web. That means: binary, type safe data structures and APIs, RPC, cryptographic sessions and user identification.

It also means code that’s sandboxed and streaming, UI that has great layout management yet is also responsive and styleable, some way to blend documents and apps together as well as the web does, and a very productive development environment. We also need to consider the politics of the thing.

I’ll take a look at these other aspects in a future post.


What should follow the web? was originally published in Mike’s blog on Medium, where people are continuing the conversation by highlighting and responding to this story.

Know your shit, MF.

Sep. 25th, 2017 12:18 pm
leo_sosnine: (Default)
[personal profile] leo_sosnine
Отдельно хочется ещё раз прокомментировать вот это кретинское высказывание:



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

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

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

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

Например:



А ведь это пионеры, совершившие прорыв. Которые по всем канонам должны были зохавать рынок. Который в те времена был завален говном типа "Циррус лоджик" или "Эс три трио".

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

Поэтому, успешный CISO успешной компании ДОЛЖЕН уметь в инфобез. Сюзан Молдин же, держу пари, ни в шелл-код написать, ни в ассемблер, ни в программирование, только одни "comm + direction" (неверные, само собой) на которые её же собственным подчинённым, из тех кто шарят в деле, насрать и её же они презирают за регулярное несение чуши на публике.

Потому что "comm + direction" должны быть хотя бы приблизительно верными. Этот самый пресловутый "vision" это просто абстракция, генерализация трендов, которые, в свою очередь являются абстракциями и генерализациями данных, полученных на земле, и т.д. и т.п. вглубь вплоть до шелл-кодов и ассемблера.

Если нет глубокого знания, то руководитель не сможет отличить хорошо оформленный отчёт, но ошибочный или ложный о трендах от адекватного и верного отчёта, т.к. не сможет прикинуть что стоит за теми или иными цифрами вглубь вплоть до шеллкодов и ассемблера хотя бы в отношении некоторых фрагментов отчёта и поэтому не сможет оценить валидность отчёта вцелом. И так всегда, во всех отчётах, год за годом.
[syndicated profile] ecworld_feed
В продолжение темы ускорения работы правительства / ЦБ в отношении финсектора:

В Госдуму внесен законопроект, ограничивающий предельную сумму микрозаймов по всем договорам физлиц, независимо от даты их заключения (с) http://www.banki.ru/news/lenta/?id=10027072

Просто, вносят закон, который действует для договоров, которые были заключены, до даты его принятия - то есть ЗАДНИМ ЧИСЛОМ. Вдумайтесь. Закон подпишут - и ряд моделей этого бизнеса (МФО) умрет сразу. Задним числом (ибо маожинальность, вопреки расхожему мнение, не безумная, если компания работает в белую).

Таким образом, МФО постепенно загоняют в тень, где ставки будут совершенно другие. А, ведь, это востребованный кусок пирога. С учетом того, что идет национализация банковского сектора, новые государственные (бывшие частные) банки будут переходить на скорринг Сбера / ВТБ, то есть многим категорям граждан кредита в банке не видать как своих ушей. Вариант будет один - к дяде в подворотне. Если МФО добьют.

P.S. Забавно, как в этом случае сработает окошко Овертона. Сейчас все с радостью будут комментировать этот законопроект: типа, так им и надо, мфо не нужны и т.п. И никто не обратит внимание на элемент "заднего числа". А завтра Дума выдаст еще пару-тройку изменений в законодательство, которые задним числом что-то вам запретят или введут ответственность (например, за ваши комменты в сети, которые раньше были вполне законны) или за просмотр видео с участием государственного лица и порочащее его честь. Хороший прецедент.

P.P.S. Ну, и ЦБ / правительство нам в ближайшее время еще пару новостей подкинет. По теме ДКП и кредитной темы (банки, коллекторы). Знаете же почему?

_
Если Вы хотите понимать, что происходит вокруг Вас, а также получать больше полезной информации и получать ее более оперативно, поставьте приложение Telegram и присоединяйтесь к нашему новому каналу - http://t.me/ecworld - заходите и обязательно нажимайте внизу канала кнопку JOIN.

alex_vinokur: Sea---2014 (Default)
[personal profile] alex_vinokur
Летала, кружилась и бегала,
Но за поведение дерзкое
Вины за собою не ведала
Красавица Оля Мещерская.

Ей тот, кто работал с мадоннами,
Дорожку ковровую выстелил
На годы счастливые, долгие.
И разом закончилось - выстрелом.

И только наставница классная,
Живущая выдумкой собственной,
Поймёт ученицу прекрасную
С душою нисколько не родственной.

Однажды случайно подслушала -
Делилась с Субботиной тайнами.
То было мгновение лучшее,
Теперь оно в небе растаяло.

...Меня согревает предчувствие,
Рождённое странным желанием,
Что вспомнится наше присутствие
И Бунина "Лёгким дыханием".

2017

Profile

jahr: (Default)
jahr

August 2017

S M T W T F S
  12345
6789101112
1314 1516171819
20212223242526
2728293031  

Style Credit

Expand Cut Tags

No cut tags
Page generated Sep. 26th, 2017 07:11 am
Powered by Dreamwidth Studios