в цялата объркана реалност, в която живеем на последък, все пак се случват островчета нормалност, които някак дават сили и надежда.
наред с WebIt, наред с TEDxBG идва и Digitalk
два дена. прекрасно място. много хора. великолепни хора. актуални теми. забавно поднесени. срещи. разговори. идеи. вдъхновение.
малко повече писахме в блога на ABC Design
поздравления за екипа на #digitalk2014!
Снощи “откраднах” тези рози от “тайния” квартален розариум.
Реших да им направя няколко хубави снимки, за да не е смъртта им във ваза безсмислена.
Вече разказах накратко за началото на DigitalK, но не си мислете, че това е била единствената интересна част от първия ден. Тук идват още четири от най-интересните презентации в програмата.
Uber е интересна идея с брилянтна реализация. Към момента работи в 35 държави и над 110 града само за 4 години. Платформата е проста, удобна и не изисква кеш транзакции. Когато се опита да обясни успеха на системата, той го обясни така: Strong product experience that is easy to share with friends.
При работата на различни пазари Jambuсе е уверил, че в различните държави потребителите до голяма степен търсят едно и също. Хората в Париж искат същото като тези в Сан Франциско. Но в същото време на местно ниво има дребни различия. В Лондон хората харесват Uber заради различните възможности при пътуване, а в Русия се търсят много луксозни автомобили. Компанията спазва общата стратегия на глобално ниво, но се адаптира към локалните вкусове. Интересно е, че новите градове, в които Uber започва работа, са по-успешни от Сан Франциско – това показва, че Силиконовата долина не е единственото място за дигитален успех.
И за финал, не се страхувайте да бъдете забавни и да започнете работа в нови ниши. С Uber вече може да си поръчате кола за сладолед, хеликоптер или да използвате куриерска услуга от врата до врата. Винаги има накъде да растете.
29% of apps are used only once and then deleted.
Click To Tweet - Powered By CoSchedule
Heather Leismanот HotelTonight представи една доста смела концепция за света на мобилните приложения. Често създателите са изкушени да набутат възможно най-много функции в приложението, а това може да е много вредно. Потребителите мразят най-много бавното зареждане, сложната навигация и търсене, а приложенията страдат от това, че не могат да бъдат намерени в директориите за приложения. За всичко това има едно решение – простота. Не се страхувайте да ограничите възможностите на потребителя и да създадете приложение, което удовлетворява само най-стандартния потребителски сценарий. За HotelTonight– приложение, което ти предлага ограничен брой възможности за резервация за днешния ден, това явно работи.
Heather изведе интересна статистика. Европейският потребител има средно 25 приложения на смартфона си. 29% от приложенията, които сваляме, се ползват само веднъж и след това се изтриват. Трябва добре да познавате своите потребители, за да преодолеете тази бариера.
Марката е съвкупност от историите, които разказвате
Click To Tweet - Powered By CoSchedule
Фирмата не е марка, продуктът не е марка, историята на компанията ви също не е марка. Марката е съвкупност от историите, които разказваш на аудиторията си и, в идеалния случай, истории, за които на аудиторията й пука. Така започна Jeremy Bernstein от Deutsch NY. След толкова технологично-фокусирани презентации беше интересно да видим тема за брандинг и комуникации, която обръща внимание на човешката страна и принципи, които познаваме отдавна.
Джереми започна с основното в дигиталната среда. Вече не разказваме истории, а ги създаваме съвместно със своята публика. Не говорим на хора, а разговаряме заедно с тях. Силната история изпълнява няколко основни функции:
Историята не винаги разказва директно за марката – най-добрите примери са свързани с ценностите на марката, а не директно с нейната история. Ярки примери за това дават Dove Real Beauty Sketches, Red Bull Stratosи кампанията на Coca-Cola Share Happiness.
За разказването на истории са важни няколко неща. На първо място, винаги трябва да си забавен и интересен. Няма твърде сериозна тема, която да не подлежи на интересен прочит – дори въпрос като инфлацията е интересно представен с кампанията на PNC Bank Christmas price index. Марката трябва да се старае да е полезна на публиката, да добавя стойност. Трябва да говорим на език, който аудиторията ни разбира – едно доказателство, че този подход работи добре, идва от представянето на Mob City в Twitter. Важно е и да не забравяме да слушаме аудиторията си – пример от PNC Neighborhood Wishlist.
Всички тези съвети не са толкова свързани с технологиите, колкото с това просто да се държим като хора. Марките трябва да се държат като човешки същества, а не като организации.
Fraser Davidson от Javelin Group разказа повече за промените в ритейл-индустрията, като се фокусира основно върху тендеции от Западна Европа и Великобритания, конкретно.
Първата вълна на онлайн индустрията идва в средата на 90-те, когато се създават първите онлайн магазини. След 2000 година идва втора вълна, в която се появяват нови търговски канали. Това е времето, в което съществуват едновременно онлайн магазини и физически вериги. Днес вече ставаме свидетели на третата вълна, тази на omnichannel продажбите. Потребителят просто иска да получи своя продукт – дали това ще стане физически в магазина, дали ще поръча онлайн и ще го вземе на място, дали ще реши да поръча през мобилния си телефон с доставка до вкъщи. Днес потребителят има възможност да направи всичко.
А технологията и интернет променят търговията бързо и значително – 50% от покупките са направени или повлияни от интернет, като се очаква това число да се увеличи. До 2022 година Amazon ще е най-голямата ритейл компания, задминавайки Walmart. За по-малките играчи обаче средата става по-сложна. Производителите също отварят собствени магазини, което увеличава броя на конкурентите, а с интернет пазаруването повече хора започват да купуват от чужбина.
За да оцелеят, търговците трябва да изпълнят няколко условия:
Основен акцент в презентацията беше промяната. Ако не се променяш в динамичната дигитална среда, няма да оцелееш дълго.
Впечатления от втория ден на DigitalK идват скоро.
___
снимка: @alicedotli
Постът DigitalK 2014 – ден първие публикуван в Васи ли?!. Ако искате да получавате повече съдържание от блога, абонирайте се за нюзлетъра.
Предлагаме ви разговор (на Валентин Дишев - от 09.04.2014 г.) със Светлозар Желев за “Дивата природа” (Deja book, 2014) от Белослава Димитрова; и за издадените от издателство „Колибри” “Цветница”от Кърт Вонегът и “Нашите предци”от Итало Калвино; за новото издание, с нов превод на (вече) “6.66 евро”и за “Един френски роман”от Фредерик Бегбеде:
(първа публикация - в електронното мултимедийно списание за литература DICTUM)
вълнувах се много. като малко дете на голям празник. дойдоха толкова много хора днес в парка, толкова много приятели! познати и непознати. с децата си. с кучетата. с още приятели.
времето беше намръщено, но ние бяхме много усмихнати. беше емоционално. беше леко хаотично. беше много ДЕОСко.
дойде едно момиче, пътувало от Брюксел специално за учредяването на ДЕОС. дойдоха хора от Хасково, Велико Търново, други краища на България.
бяхме в парка. партиите обикновено се учредяват в зала. с наем, ток, книжки и строго гласуване. ние избрахме, както във всичко до тук, а надявам се и в бъдеще – да сме различни. паркът ни беше идеалното решение. лятната естрада – великолепна.
гласувахме предварително онлайн членовете на Управителния съвет и на Надзорния съвет. единствените структури, които законът изисква да има всяка партия. в ДЕОС взимаме решения социократично. ще рече – за да се вземе едно решение следва никой да не е против. това се постига чрез говорене, разговори, спорове, убеждаване, комуникация. затова и хората в УС ще имат по-скоро формални функции. всички решения ще се взимат от всички ни, чрез онлайн платформа за гласуване.
мда, мнозина очакваха че аз ще съм в УС или в НС или ще имам някаква “ръководна роля”. е, в ДЕОС всички сме равни. затова и съм извън НС и извън УС. ще работя активно за идеята, както и до сега. вървим напред. заедно и само заедно ще успеем да променим посоката.
при Надзорния съвет е една идея по-различно. тези хора не са членове на ДЕОС, но имат задачата да ни дават знак, когато сме кривнали от набелязания път или сме се вторачили прекалено дълго в нещо незначително, например. любопитен детайл е, че преди днес бяхме решили, че НС ще се състои от 5 души, но днес бе предложен нов член, в допълнение друг се самопредложи и напълно по ДЕОСки решихме, че НС ще е съставен от 7 души и така 
(вероятно няма друга подобна случка в която и да е партийна история).
ДЕОС не сме нито леви, нито десни. ДЕОС сме либерален проект, роден от протеста. намерихме се на площада, след месеци наред по жълтите павета. мислим, че свободата е върховно благо за всеки. свободата е над демокрацията. че всички хора са равни. че инициативата и предприемачеството следва да се насърчават. че държавата трябва да се меси по-малко на всяко ниво.
за ДЕОС основните приоритети за реална промяна са три: образование, правоприлагане, устойчиво развитие на бизнеса. вярваме в електронното гласуване. вярваме в пряката демокрация. вярваме в спазването на законите. вярваме в равенството в брака. вярваме, че сме нещо ново, което дава надежда.
не обещаваме спасение в 800 дни. не раздаваме кебапчета. нямаме лидер. не сме ГМО проект, финансиран и управляван задкулисно. не сме кьорфишек нито пирамида.
вярваме в промяната. и в това, че заедно можем повече.
защото утре е днес.
отново да благодаря на всички приятели, които дойдоха и подкрепиха създаването ни!
ако ДЕОС като политическа платформа е близо до теб – ела при нас!
Smallman си издадоха третия албум и направиха концерт в Terminal 1.
(аз цял ден бях на websummit-а, дето не спрях да говоря, и накрая даже имах лекция (която ще кача по-късно). Стоях прав през цялото време и сега ми е малко уморено… Имаше весела случка – загубил съм си калъфа за очила и понеже трябваше да ги нося в раницата, ги сложих в една от картонените кутийки от вазелина, дето червото ми беше подарил за рождения ден. После беше останала някъде отзад на нашия щанд, чудя се дали е притеснила някого).
Преживяването беше супер. Свириха си новия албум и доста от хубавите стари неща
(например Ocean), не говориха много, просто свириха и радваха хората (аз мисля, че бях ухилен през повечето време). Дори невероятната гъчканица (билетите бяха свършили бързо, даже 80те допълнителни за разпродаване на входа) не можа да ми помрачи удоволствието.
И мисля както съм вече прилично неадекватен да си легна.
Един от най-милите празници в годината настъпи и ако още не сте решили с какво да изненадате своето дете, нека това да бъде едно приключение! Дали ще е истинско, или в измисления свят на приказките – решете сами. Днес обаче мислим да ви подскажем, че мотовете на Радостина Николова отново са тук и ако има нещо, което не им е чуждо (освен попръцкването), то това са именно приключенията!
Ако не знаете що за същества са това мотовете, може да се запознаете с тях в една от по-старите ни публикации, когато си говорехме за Мукси неговата сговорна дружина от сладки мотчета.
Във втората част, озаглавена „Мукс отвръща на удара„, ни предстои да се срещнем с един не толкова пухкав, мил и симпатичен клон от родословното дърво на мотовете, а именно – моДовете. Една единствена буквичка в името, а каква разлика!
Та модовете са всичко лошо, което може да си представите – злобни, глупави и адски миризливи. Мразят всичко шарено, весело и с приятен аромат, затова когато добрите герои разбират за пъкления им план да направят Мотилияедно страшно и безцветно място, веднага измислят най-пъстрия начин да спасят както себе си, така и своите приятелчета – децата. Да, ама нищо не е толкова лесно, колкото си мислим ние!
Разказът е изпълнен със страхотните илюстрации на Мелина-Елина Бондикова, а приключенията ще се харесат на всяко детенце, защото са простичко описани, така че да се впишат в разбиранията на децата, които мислят в контрастите добро-лошо, любов-омраза. И като стана дума за любов, накрая ще има една много щастлива принцеса и един много щастлив Мукс, но това да си остане между нас. ;)
Още за света на мотовете – тук!
Девора
Приятели:
Честит празник! 
Две седмици по-късно, спомените от тазгодишния Фантастивалоще ни греят усмихващо. Ето такивапразници искаме – пак и отново!
Тъй като духът ми е на по(д)растващ, но паметта ми застарява 
– в представянето на Фантастивала ще си помагам с програмата му. Добавям към събитията материалите, които нашите участници-съратници ни предоставиха. (И само с тях ще си играйкам вече… ето такиваучастници искаме – дето да съ-участват с всички сили и усмивки! 
) Ако някъде липсва материал – ще го качим по-късно (или нямаме).
Петък, 16 май
17.30: Откриване на изложбата
18 до 22 ч.: Юбилейна вечер „40 години непрекъсната дейност на клуб по фантастика, прогностика и евристика „Иван Ефремов“
Събота, 17 май
16:00: Антологията „За спасяването на света“ и Човешката библиотека: място, на което дръзваме да мечтаем дръзко
Представя: Калин М. Ненов
-> звукозапис (заедно с кръглата маса после)
16.30: Кръгла маса: „Позитивни модели на бъдещето и устойчиво развитие“
С участието на:
Атанас П. Славов, Дружество на българските фантасти „Тера Фантазия“, писател
д-р Михаил Малеев, бивш директор на музей „Земята и хората“, геолог и минералолог
Вал Тодоров, социален активист, режисьор и писател, създател на българския клонна Indymedia.org
Калин Ненов, доброволец в природозащитното движение, участник в образователна мрежа „Място за бъдеще“ и Човешката библиотека
и други
-> звукозапис (заедно с представянето на „За спасяването на света“)
Неделя, 18 май
11.00: Награждаване на участниците в Копнежа за растящо творчество
Награждават: Кристиана Тошева от Фентъзи ЛАРП център, Петър Атанасов от SciFi.bg, Калин М. Ненов и Лъчезар Енчев от Човешката библиотека
-> звукозапис (заедно с представяне на „Аурелион“)… и вижте най-долу
11.30: Прожекция на сериала „Аурелион: Вечният баланс“ и среща с клуб „Светлини сред сенките“: Как създаваме истории заедно
Представят: Анелия Стойкова, Калин М. Ненов
-> звукозапис (заедно с награждаването от Копнежа)
Click here to view the embedded video.
12.30: Бордовата игра Bright Future
Представя: Радомир Мирчев (Гадина Проклета)
-> презентация, звукозапис
13.00: обедна пауза
14.30: Фентъзи ЛАРП център
Представя: Кристиана Тошева
-> презентация, звукозапис
15.00: 60 години Godzilla
Представя: Александър Драганов, Цитаделата / Национален клуб за фентъзи и хорър „Конан“
-> презентация, звукозапис
16.00: SciFi.bg
Представя: Петър Атанасов
-> презентация, звукозапис (заедно с Iscariot)
16.20: Kъсометражният филм Iscariot
Представят: Петър Атанасов и сценаристът Анди Михов
-> звукозапис (заедно със SciFi.bg)
16.40: Представяне на ларп, включително „Сталкер“
Представя: Радомир Мирчев (Гадина Проклета) и ансамбъл въоръжени до зъби ларпъри
-> звукозапис
Click here to view the embedded video.
17.30: Прожекция на авторски анимации
Представя: Дивна Вълчева
18:00: Прожекция на филма „България, тази вечна ерес“
Представя: Вал Тодоров, режисьор и сценарист
А ето и кого отличихме в Копнежа за растящо творчество тази година:
Отличия от Фентъзи ЛАРП Център
Отличия от електронно списание SciFi.bg
Отличия от фондация „Човешката библиотека“и клуб „Светлини сред сенките“
… Догодина – още повече! И още по-хубави!
Да?
[slide 2 Идеята за тази лекция]
Идеята за тази лекция ми дойде около няколко разговора с различни хора и от нашият опит с правенето на pCloud. Много често ни се случваше да погледнем конкуренцията как е направила нещо и да се ужасим в първия момент.
(а след това да се зарадваме, че се срещу нас има такива хора)
За всичките неща, за които ще говоря има лесни решения – прости като идея и сравнително лесни за реализация, като правенето им трябва да доведе до един по-добър свят.
Също така в историята има много случаи на проблеми, които са се случвали и за които всички са забравили или просто са отказали да обърнат внимание.
Нищо от това, което ще кажа не е особено ново, гениално или изобщо велико откритие. Всичкото е откриваемо с малко четене в google, wikipedia и от време на време някоя книга. Извинявам се предварително, че нямаме осигурени възглавници за хората, на които ще им се доспи от скучните неща, които ще разказвам.
(ако четете това като текст – нищо против нямам да го ползвате за приспиване)
[slide 3 Защо ние го говорим това]
Ние харесваме добре написаните неща. Също така се стараем да сме максимално отворени откъм API, код и т.н., и за това държим да правим неща, от които да не се срамуваме, или даже да се гордеем с тях.
Също така съм съвсем наясно, че тази лекция звучи като безкрайно фукане. Поне половината е такава :) За това искам да отбележа, че доста от тези грешки сме ги допускал и ние, в този или предишен проект.
[slide 4 Кои сме ние]
Минутка за реклама – ние сме cloud storage услуга, направена правилно. Startup сме, има ни от около година, имаме около 600k потребители и 600TB заето място и правим всякакви интересни неща, за които обаче ще ми трябва тричасов слот, че да ги изброя :)
Стараем се да сме максимално отворени – имаме пълна документация на API-то ни, както и код, който си говори с него. Ние самите за приложенията, които пишем ползваме същото API, т.е. не крием нищо от разработчиците :)
[slide 5 Authentication]
Почти всички услуги трябва да пазят в някакъв вид пароли за потребителите си и да им дават да влизат в системата, за да получат достъп до някаква допълнителна функционалност. Човек би си помислил, че това е изчистено и изяснено и трябва да няма проблеми…
[slide 6 Стандартен метод за auth]
По принцип в повечето случаи влизането в системата се реализира чрез изпращане на user и парола и получаване на отговор/token, с който да работим след това.
Което е лоша идея, понеже паролата ви минава по мрежата в някакъв вид, и не може да сте сигурни дали някой не подслушва или дали някой не се прави на отсрещния сървър.
[slide 7 Правилен метод]
Правилният метод, който използва един прост криптографски примитив, се нарича challenge-response. Има и реализация в самия HTTP протокол, т.нар. digest authentication, както и в много други системи (например SIP). В web твърде рядко се среща, поради нуждата от още една заявка (или поради неинформираността на разработчиците).
Работи по следния начин:
Сървърът ви генерира nonce – някаква стойност, която е произволна, няма да се повтори пак. Смятате криптографски hash в/у нея и паролата и изпращате резултата на сървъра. Той от своя страна може да направи същото изчисление и да разбере, че вие знаете същата парола.
Така никаква информация за самата ви парола не минава през мрежата, така че дори някой да се представя за сървъра, няма начин да бъде научена.
Методът е по-бавен от другия, понеже изисква още една заявка (да си вземете nonce, с който да работите), т.е. вкарва още един round-trip. Това не е проблем, понеже това така или иначе не трябва да е особено бърз процес – т.е. колкото по-бърз е, толкова по-лесно може да се използва за brute-force атаки.
Тази схема с малко разширяване дава възможност и клиентът да потвърди, че сървъра има паролата (т.е. да се получи двустранна auth.), което ще ви оставя за домашно :) Ние все още не го реализираме, но е в плановете за светлото бъдеще.
[slide 9 Plaintext в базата данни]
Пазенето на паролите се оказва проблем, който твърде малко хора успяват да решат.
Така като гледам, сме 2014, и все пак се случва някоя сериозна услуга да пази паролите в plaintext. Това в някакви моменти е удобно – lost password функционалността може да ви прати директно паролата по пощата (сигурността на което няма да обсъждам).
От друга страна обаче, поне няколко услуги биват hack-нати всяка година и паролите им попадат в ръцете на лоши хора (или в целия internet). Това е доста неприятно за потребителите, понеже те въпреки съветите на експерти и други заблудени люде все пак използват същата парола на много места, което води до допълнителни пробиви и подобни неприятни проблеми.
(съвсем скорошен пример – преди седмица-две-три източиха на ebay паролите)
[slide 10 Първи лесен (и грешен) вариант]
Първото решение на проблема, което е лесно и грешно, е просто да се съхранява някакъв криптографски hash на паролата – md5 (много-лоша-идея) или sha1 (не-толкова-лоша идея). Това се атакува тривиално с rainbow таблици.
Съвсем накратко, rainbow таблиците са пресметнати таблици с (почти) всички възможни пароли, така че лесно да може да се намери в тях някакъв валиден string, който да отговаря на дадения hash. Също така имат метод за съхраняване на по-малко данни, та по принцип за md5 таблиците са под 2TB, за sha1 има таблици с повечето пароли пак в някакъв такъв размер.
Накратко – лоша идея.
[slide 11 Втори лесен (и правилен) вариант]
Второто решение (и първото работещо) е известно на света от поне 1970та година, от хеширането на паролите в старите unix системи, дори в повечето езици името на функцията – crypt() идва от там (тя дори не криптира).
Идеята е проста, генерираният hash да е на някакъв salt и паролата. Salt-ът се подбира да е различен за всяка парола, и се слага преди получения hash. Така лесно може да се пресметне, но не може да му се генерира rainbow таблица (т.е. ако се генерира, ще трябва да съдържа и възможните salt-ове).
[slide 12 Трети не-толкова-лесен (но правилен) вариант]
Третият вариант, който може да се използва (и който сме реализирали при нас) е да се пази “частичен” hash на паролата (т.е. по-точно пълния state на hash функцията) и някакъв salt, така че да може и да се реализира challenge-response. Това ни отне малко повече време за реализация, но така не пазим пароли в plaintext и можем да реализираме challenge-response, за да гарантираме максимална сигурност на потребителите си.
Много близко е до lenghtening атаката в/у хешове.
( Корекция след самата лекция: Реално погледнато, challenge-response може да се реализира дори с хеширани пароли по предишния начин)
[slide 13 Четвърти (велик и труден за правене) вариант]
И последният метод, който дава най-голяма сигурност, и който не съм виждал реализиран никъде, освен на една лекция. Идеята му е в общи линии като на password-authenticated key agreement протоколите, повечето от които поне доскоро бяха патентовани и като цяло не се срещат особено често.
На база на паролата се захранва един pseudo-random генератор, от който след това се генерира двойка RSA ключове (частен и публичен). На сървъра се дава само публичния ключ, а клиентът няма нужда да пази нищо, понеже от паролата може да генерира същата двойка когато си реши. Автентикацията става чрез стандартните схеми за RSA и дава възможност да се пазите от всичките атаки по-горе, и дава още едно ниво на сигурност – ако някой ви се добере до базата на сървъра, с информацията после няма да може даже да влиза при вас, т.е. даже няма да има нужда потребителите да си сменят паролите.
За съжаление не съм виждал никъде реализация на схемата. Описанието и видях в една лекция на Дан Камински преди няколко години.
[slide 14 Further reading]
И понеже темата е доста обширна, може да потърсите този стандарт – password-based key derivation function, както и да погледнете конкурсът за нови такива алгоритми за съхраняване на пароли, може да са ви полезни.
Специално PBKDF2 показва едно доста важно свойство на всички тези схеми. Важно е проверката на паролата да не е максимално бързо действие, а да отнема някакво малко, но достатъчно време, така че да да се направят brute-force атаките по-трудни.
Самият PBKDF е схема за прилагане на хеш функция много пъти (1000, 10000 или нещо такова) върху входни данни и salt, така че от това да се получи някакъв набор битове, които да се използват или като съхранена парола, или като ключ за нещо друго. Поради големия брой действия, които няма как да се направят по-лесно, лесно може да се сметнат параметри, които да ви дадат нещо като 10ms за извършване на сметката, което да доведе до невъзможност да се правят повече от 100 теста в секунда на един core.
М/у другото, пример за използвана такава схема е WPA при wi-fi мрежите – там ключът за комуникация се генерира с pbkdf2 с 1000 пъти sha1 и essid-то (името) на мрежата за salt. Ако някой е пробвал да чупи такива пароли знае, че върви доста по-бавно, отколкото просто на хешове.
[slide 15 Комуникация]
Изразът с тъпата брадва идва от едно изречение на Дийкстра, “Молив не може да се наостри с тъпа брадва, същото важи и за 10 тъпи брадви”. Подобен израз, който може би е по-подходящ (и за който се сетих на лекцията) е “Манчестърска отвертка” – която всъщност е чук, идеалният инструмент за решаване на всякакви проблеми.
[slide 16 Стандартни неща]
По принцип всичко живо използва JSON и HTTP. Те са бавни протоколи, текстови, с много overhead и не-чак-толкова удобни за parse-ване (добре поне, че има такива библиотеки в почти всеки език).
Да не говорим, че HTTP е мислен за съвсем различни неща от тези, за които се използва в момента.
[slide 17 Трябва алтернатива]
Добре е да имаме алтернативи. Не всичките ни клиенти са browser-и, но всички са принудени да ползват интерфейси, писани за тях, което е доста неприятно и на моменти – много неефективно (но понеже хората са свикнали, вече не обръщат внимание). Най-добрият пример е какво ползват мобилните приложения – все http базирани api-та, а те уж са устройства, които трябва да пестят от батерия и CPU колкото се може повече.
Дори в самите browser-и вече не е това единственият подходящ и ефективен начин – в момента навлизат websockets и webrtc, точно заради това.
(имах въпрос от публиката после защо нещо не съм много оптимистично настроен по темата webrtc, човекът (Лъчко всъщност) се надявал да може да замести skype – понеже това, което реално успява да прави skype е да работи през всякакви мрежи и NAT-ове, което за останалата телефония е сложно и не се справя толкова добре. Webrtc-то още не е стигнало да бори наистина сериозно такива проблеми и вероятно ще му трябва доста време, докато започне да се справя с тях).
[slide 18 Примерен binary протокол]
По тази причина ние сме направили допълнителната възможност да може да се комуникира с интерфейсите ни през просто binary api.
Като казвам просто – то наистина е такова, описанието му се събира на няколко страници, реализацията (която имаме публикувана в github) е 700 реда на C или 536 реда на java, заедно с коментарите. Има много по-малко overhead, и се обработва много лесно на всякаква платформа. Също така в себе си има няколко хитрини, например ако в даден пакет определен string се среща повече от веднъж, съдържанието му се пази само на едно място и останалите са reference.
Разбира се, има и други варианти – в един предишен проект сме използвали protobuf (който се оказа доста удобен), има msgpack и какви ли не още отворени проекти с публични реализации за повечето платформи.
(ползвали сме protobuf за един друг проект и даже аз, дето по принцип не пиша код се оправих съвсем лесно да си parse-вам данните)
[slide 19 QUIC и пътят напред]
И да слезем по-надолу – един от проблемите в съществуващите протоколи е, че осъществяването на връзка е бавно. Нужни са 3 пакета (и 1 RTT), за да се осъществи връзка м/у две точки по TCP, а когато добавим SSL/TLS, добавяме и още 2-3 RTT-та в зависимост от някои настройки на протокола.
Едно от съществуващите решения е разработка на google, казва се QUIC – Quick UDP Internet Connections, протокол, който замества комбинацията от TCP+TLS. Има в себе си всички полезни неща от TCP, като правилните алгоритми за напасване на скоростта и congestion avoidance, но криптирането в него е по подразбиране, и осъществяването на връзка става в рамките на едно rtt, заедно с избирането на ключове и т.н..
Има също така интересни feature-и, като например multiplexing – да се обработват няколко заявки в една връзка (като в SCTP). Друго нещо е forward error correction, да може да коригира грешки в пакетите или изгубени такива по вече пратени данни.
Ние сме в процес на разглеждане на протокола, ако ни хареса достатъчно, мислим да го използваме. В момента има поддръжка в chrome и opera, ако придобие достатъчно разпространение, ще реши проблема и с firewall-ите. Разработката на google е пусната под BSD лиценз, и е сравнително малко код на C++, та би трябвало скоро да се появи и на други места.
Като цяло, струва си да прочетете описанието, протоколът е пример как трябва да изглежда следващото поколение internet протоколи.
[slide 20 Употреба на SSL/TLS]
Ако не сте живели под камък в последната година и половина, вероятно сте наясно защо е важно да се ползва криптиране на връзките и по принцип SSL/TLS.
(ако сте, питайте търсачките за Edward Snowden)
Вече повечето услуги имат поддръжка за TLS – отне години и доста лобиране/мрънкане от страна на общността, но е често срещано. Не винаги е реализирано правилно обаче…
[slide 21 Правилна употреба на SSL/TLS]
Първото е, че в твърде много случаи не се обръща внимание на шифрите, които се използват, съответно сигурността на връзката с някои места е почти същата като за без криптография. Пример за това е как преди около година Android смениха списъка си с поддържани шифри/алгоритми и приоритетите им, понеже “в java стандарта било така” (предишния им списък беше взет от openssl). Java 6 е стандарт на около 10 години и в новия е оправено…
Друго важно нещо е т.нар. forward secrecy – това е възможността след осъществяването на връзката двете страни да разменят през DH или друг алгоритъм ключове, които са само за тази сесия и се забравят след нея. Така се подсигуряваме, че дори да изтекат главните ключове на сървъра, то записаната от преди това комуникация няма да може да се декриптира и ще остане тайна.
За заинтересуваните хора, които имат сървъри – на този сайт може да проверите поддръжката си на подходящите алгоритми и шифри, резултатът може да ви е интересен.
И разбира се, SSL/TLS не е панацея, и те имат собствени проблеми (като например heartbleed наскоро).
[slide 22 SSL/TLS Session caching]
За услуги, които имат повече от един физически сървър, който поема криптираните сесии (но на същия domain), има друг полезен момент – да се реализира глобален SSL session cache, който да пази определени параметри, за да не се renegotiate-ват всеки път. Това спестява едно RTT от всяка заявка и определено се усеща.
За целта може да ви се наложи да използвате някакъв backend storage (memcache или redis), в който всичките ви сървъри да пазят тези сесии, но да се подкара не е особено сложно и може да има видим ефект за потребителите ви.
[slide 23 Privacy]
Много услуги правят грешката да разкриват информация за потребителите си, която реално не трябва да излиза извън тях. Например често през някоя функционалност, като lost password или invite може да разберете дали даден потребител е регистриран в услугата.
Това е неприятно, понеже улеснява всякакви атаки в/у вашите потребители, особено ако не сте ориентирани към разпространяване на информацията на потребителите ви и продаването и/им (като почти всички социални мрежи)
(корекция от публиката на лекцията – всички социални мрежи)
Примерът за разкриването дали даден файл (което btw е проблем, който идва основно от дедупликацията в повечето такива услуги) е как един определен service можеше да му кажеш “аз ще ти кача файл с тоя MD5″ и той казваше “а, аз го имам, заповядай”. Това за известно време сериозно се използваше за share-ване на файлове без реално да се вижда какво става…
[slide 24 Не всички клиенти са равни]
Изобщо, на моменти имам чувството, че много от интерфейсите са правени от някой, който приятелката му го е зарязала заради някой developer и той сега държи да си го върне. Представям си човек, който стои в тъмна стаичка, пише спецификация и си мисли “и аз на теб да ти го …”…
Няма един правилен интерфейс, един правилен начин, един пръстен, който ги владее и т.н.. Колкото и да ни се повтаря от някакви хора, които нямат въображение, няма да стане вярно :) Има нужда от интерфейси, който да са удобни за различни хора, по различен начин, от различни среди и различни начини на мислене.
[slide 25 Предаване на параметри]
Например, предаването на параметри. При нас параметър може да бъде предаден където ви е удобно – като GET, като POST, в URL-то на POST-а, или в cookie. Даваме ви възможност за прострелване в крака, но от друга страна ви даваме начин да ни ползвате от възможно най-простите клиенти на тоя свят, които нямат POST.
[slide 26 обработка на request-и в движение]
Нещо, което е повече в категорията “имам тъпа брадва и искам с нея да остря моливи” – ужасно много услуги обработват заявката, след като я получат цялата. Ако качвате файл, който трябва после да отиде по други машини, имате една очевидна латентност, дължаща се на последвалата обработка.
Това се дължи най-вече на ползването на HTTP и криви сървъри, и като цяло може да не е така – повечето content може да се обработва в реално време, докато се качва – да се копира на други места, да му се смятат checksum-и и какво ли не още. Не е нужно да караме потребителите да чакат, само защото нас ни е домързяло да направим няколко прости подобрения.
[slide 27 blatant self-promotion]
И оставащата част от презентацията е хубави неща, които са специфични за cloud storage услуги, или “защо ние сме по-добри от останалите”. Не само ние правим тези неща, но май само ние правим всичките.
[slide 28 Thumbnail combining]
Нещо, което пак идва от тъпата брадва на HTTP/AJAX и компания – ако имате да покажете галерия от thumbnail-и, няма смисъл да ги дърпате един по един. Много по-ефективно е да може да ги комбинирате в един голям файл и да ги показвате, докато пристигат.
Конкретните методи за това са доста грозни (thumb-овете, изредени по един на ред в base64 и се декодират после), но си личи промяната в скоростта.
[slide 29 On-the-fly zip]
Нещо, което идва основно от мързела на разработчиците – не е нужно да генерирате zip файл и така да го дадете на потребителя, може директно да му го stream-нете, понеже zip-ът е такъв удобен формат (явно идва от времената, в които е трябвало да може да се пише на лента). Не е единственият такъв, но е пример за как някои неща могат да се случват моментално, вместо да се изчакват.
[slide 30 Rsync-подобен протокол]
Rsync съществува като идея от времената, в които аз бях младши системен администратор, но по някаква причина не се среща достатъчно често като идея в повечето услуги.
Идеята е много проста – ако от едната страна имате част от даден файл или негова по-ранна версия, е много по-лесно да копирате само разликите, а не целият файл. Поддържаме го и в двете посоки – и за качване, и за сваляне на файлове, като самата идея не е сложна за реализация, дори и в web приложения. Не ползваме директно rsync протокола, понеже не пасва добре в нашия интерфейс, но сме сравнително близо, и също така за една част от хешовете използваме друга функция, понеже се оказва по-удобна.
(още нямаме качена документацията за метода, понеже не остана време, обещавам да я качим в най-скоро време. Ще качим и код, който го реализира.)
[slide 31 Видео с напасващ се bit rate]
Една хубава възможност, която доста video услуги биха могли да предлагат – да се напасва bitrate на видеото към връзката ви (т.е. да не праща с повече, отколкото вие може да приемете), което прави възможно да гледате видеа и на доста неприятна връзка.
[slide 32 Файлови операции]
И накрая нещо, което е повече интересно, отколкото важно – интерфейсът за дребни промени по файловете, редакция на място е доста удобен и помага да се пренесат различни приложения и действията им директно към storage услугата.
[slide 33 Други готини неща за в бъдеще]
Тук исках да кажа и други неща, но не ми стигна времето да ги извадя.
Това е един план за светлото бъдеще (в рамките на годината) – да направим end-to-end криптиране на файловете на потребителите, т.е. да им дадем функционалност, чрез която те още при себе си да криптират всичко и да не можем да го четем, както и да са сравнително сигурни, че не не им подменяме или омазваме файловете. Би трябвало всички да го правят – реално погледнато няма причина нещата, които са лични за потребителя да могат да бъдат известни на оператора на услугата, и има доста разработки по въпроса.
Например, има дори няколко paper-а по темата за криптирана база данни – тя стои криптирана на един сървър (който няма ключовете), вие пращате криптирана заявка, сървъра прави някакви сметки и ви дава отговор от вашите данни, който също е криптиран и който само вие може да разберете. Все още нещата са в начални стадии, но са една добра идея за бъдещето.
[slide 34 Отворени сме към други идеи]
Сигурен съм, че има неща, които съм пропуснал в лекцията, и за които не сме се сетили да сложим в нашата услуга. Приемаме всякакви идеи и критики, а тази лекция винаги може да се удължи (например като за едно-семестриален курс).
Приемаме всякакви корекции и идеи – по принцип имаме натрупана работа като за 3-4 години напред, но това още не е успяло да ни уплаши :)
Много от авторите на любими ми книги признават, че са се вдъхновили да пишат от поредицата „Хари Потър“ – не непременно за конкретните истории, а да пишат по принцип. Но ролята на „Хари Потър“ в живота на Джесика Кори, автор на „Произход“ и други фантастични йънг адълт романи, е дори още по-голяма. Ето нейния разказ – за забранените книги, за порастването и за правото на избор…
В моя малък роден град в Джорджия, в който имаше 144 църкви и само един бар, „Хари Потър“ беше определян като върха на дяволските творения – съзаклятие, създадено, за да примамва малките деца по порочни пътища, водещи до морална гибел. Можех да преброя на пръстите на едната си ръка децата, за които знаех, че са прочели забранените книги, и бях наясно, че бяха тормозени заради това. Но виждах книгите в стекове в „Уол-Март“ (единственото място, където реално се продаваха книги в града ни) и, въпреки че не смеех да си го призная, те ми шепнеха.
По различни поводи дори дръзвах да се доближа на три метра от тях, заставах и ги изучавах отстрани, като се преструвах, че небрежно разглеждам шоколадчетата до касата. С равностойни срам и очарование запаметявах корицата на „Хари Потър и Нечистокръвния принц“ и се чудех какви ли думи се крият вътре. Когато мои приятели ми подшушнаха, че братовчедът на приятел на техен приятел е прочел тези книги (информация, посрещната с много гримаси и клатене на глави), ушите ми сигурно бяха почервенели. „Не мога да им кажа“ – мислех си. – „Не мога да им кажа.“
Но наистинаисках да ги прочета. Много. Дори не съм сигурна какво ме притегляше към тях. Дали това, че бяха забранени? Или пък дебелината им? Винаги съм имала и винаги ще имам слабост към дебели книги. Или пък може би изкусителните им мистериозни корици?
Спомням си деня, в който най-сетне попитах родителите си дали може да прочета „Хари Потър“. Обмислях речта си цяла седмица. Имах си набелязани етапи и шлифовани аргументи. Логично бях пресметнала, че най-добрият ми подход е: „Но ако не съм ги чела, как бих могла да се защитавам срещу тях?“.
Първата ми молба, която беше доста по-смирена, отколкото я бях репетирала, беше посрещната със звучно НЕ. Но аз не се отказах. Отне ми няколко месеца, но най-сетне постоянството ми ми се отплати. Мисля, че в един момент родителите ми се измориха от постоянното ми натякване и затова се омилостивиха. Но не ми дадоха разрешението си с гневен отговор или като капитулация, а като признание на автономията ми. „Ние не искаме да четеш тези книги“ – казаха те, – „но ти разрешаваме да прецениш сама. Вече си на 15 и ние уважаваме твоята способност да избираш. Отсега нататък е твой избор какво ще четеш и каквото и да е то, ние ще продължаваме да те обичаме и да ти вярваме.“
Беше шокиращ момент, по-освобождаващ от всичко, което някога бях изживявала. Беше много по-определяща стъпка към зрелостта ми от вземането на шофьорска книжка, отиването в колеж или първото гласуване. Това беше денят, в който родителите ми признаха и уважиха моята способност да правя избор и въпреки че не харесаха решението ми, никога не се разколебаха в любовта и доверието си.
„Хари Потър“ се превърна в повратна точка във взаимоотношенията ми с моите родители. Ако те не бяха изрекли тези думи, ако вместо това бях изчела тези книги тайно и с чувство на вина, може би щях да се превърна в съвсем различен човек. Несъмнено връзката ми с тях щеше да беше силно нарушена. Вместо това прочетох книгите без никакъв срам, влюбих се в тях и запазих уважението на родителите си въпреки различното им мнение.
Загубих ли приятели? Да. Спомням си как казах на някои от тях, че съм прочела книгите и дори че съм ги харесалаи те шокирани заявиха, че прекратяват приятелството ни и никога повече няма да си проговорим. Така и стана, не го направихме – но за моя изненада бях облекчена. Никога изпитах липсата им. Чувах как другите си шепнат: „Разбрахте ли, че Джесика чете „Хари Потър“?“ и се усмихвах.
Години по-късно щях да седна в киното с някои от тези си приятели – и дори с родителите си – за премиерата на филма „Хари Потър и Орденът на феникса“. Години по-късно щях да се озова в Хогсмийд в увеселителния парк „Вълшебният свят на Хари Потър“ с маслена бира в ръка и да плача, защото всичко беше започнало именно на това място. Точно тук беше започнала автономията ми.
Не беше порочно. Не бях засрамена. Но станах по-уверена в своите избори и в своята независимост. Много деца пораснаха сХари Потър, а аз пораснах зарадинего.
Khoury, Jessica. Harry Potter And The Forbidden Books // NPR Books, 31.05.2014.
За прилагане нарешението Google Spainсе изисква компаниите да започнат изрично да извършват оценка на баланса между свободата на изразяване и правото на защита на личните данни и зачитане на личния живот.
Googleоповести (основи на) механизъм за премахване на резултати от търсене, съответна на това решение. Г-жа Рединг, ЕК, приветства стъпката - според нея сега вече става ясно, че страховете за трудностите в практическата реализация са били необосновани.
Но трудности има. Index on Censorshipпосочва, че частни организации ще арбитрират достъпа до публична информация и напомня, че позицията на Съда се различава от заключението на Генералния адвокат.
Пейо Попов коментира серия важни въпроси в блога си - Правото да бъдеш забравен, релизация и ефекти.
Какво е обоснована и пропроционална намесав личния живот Съдът вече е обсъждал, например в решенията Комисия/ Bavarian Lager или по повод публикуване на информация за бенефициерите по европейски програми– по съединени дела C‑92/09 и C‑93/09: правата по чл.7 и 8 от Хартата могат да бъдат ограничавани при определени условия:
[50] член 52, параграф 1 от Хартата допуска налагането на ограничения при упражняването на правакато прогласените в членове 7 и 8 от нея, ако тези ограничения са предвидени в закон, зачитат основното съдържание на посочените права и свободи и при спазване на принципа на пропорционалност са необходими и действително отговарят на признати от Съюза цели от общ интерес или на необходимостта да се защитят правата и свободите на други хора.
Google са създали 7-членна комисия -имената са авторитетни и известни.
Съветът на ЕС прие Ръководни правила относно свободата на изразяване онлайн и офлайн.
Правилата изясняват международните стандарти относно свободата на изразяване. Предвиждат се ангажименти на ЕС и практически средства за утвърждаване на свободата на изразяване в ЕС.
В Приложение са посочени примери за нарушение на стандартите като враждебна реч, ограничения на медийния плурализъм, липса на независимост на медийните регулатори, ограничения на свободата на изразяване с цел защита на авторски права и др.
Всяко ограничение на свободата на изразяване трябва да съответства на определени изисквания – в т.20 се предлага тест, подобен на теста за пропорционалност, използван от Съда за правата на човека.
Комисията за защита на конкуренцията се е произнесла по уведомление, съгласно което “Медия Мейкър Лимитид“ (Media Maker Limited) – Ирландия има намерение да придобие контрол върху следните дружества: „Телеграф“ ЕООД, „Монитор“ ЕООД, „Политика Днес“ ЕООД, „Компакт – Меридиан“ ЕООД, „Експрес БГ“ ЕАД, „Пресмаркет“ ЕООД и „Издателска къща Борба“ АД.
“Медия Мейкър Лимитид“ (Media Maker Limited) – Ирландия е еднолично дружество с ограничена отговорност, чийто капитал се притежава изцяло от физическото лице Патрик Халпени. Дружеството стана известно с това, че е вписано два дни преди да се огласи публично сделкатаза придобиване на вестниците на Ирена Кръстева – Пеевски.
КЗК установява, че придобиването на 100 % от капитала на „Телеграф“ ЕООД , „Монитор“ ЕООД, „Политика Днес“ ЕООД, „Компакт – Меридиан“ ЕООД , „Експрес БГ“ ЕАД и „Пресмаркет“ ЕООД, както и на 50% от капитала на „Издателска къща Борба“ АД от страна на господин Патрик Халпени (ирландски гражданин) чрез “Медия Мейкър Лимитид“, Ирландия не представлява концентрация между предприятия, тъй като той (физическо лице) не контролира други предприятия и не осъществява стопанска дейност.
Текстът на решението - №697/27 май 2014
Европейската комисия прие Съобщение COM/2014/072 final Политиката по отношение на интернет и управлението му. Ролята на Европа за определяне на бъдещото управление на интернет.
В Съобщението се предлагат основните положения за обща европейска концепция за управлението на интернет.
Европейската комисия смята, че институциите на ЕС и държавите от ЕС се нуждаят от обща концепция за бъдещия модел за управление на интернет. Комисията планира да представи през 2015 г. доклад по ключовите моменти в тази област.
Заключението: Интернет следва да остане единна, общодостъпна, свободна и цялостна мрежа от мрежи, за която са в сила същите закони и стандарти, които се прилагат в други области на нашето ежедневие. Управлението на интернет следва да се основава на всеобхватен, прозрачен и отговорен модел за участието на различните заинтересовани страни, без това да засяга регулаторната намеса, която може да бъде предприета с оглед на определени цели от обществен интерес — например за да се гарантира спазването на правата на човека, основните свободи и демократичните ценности, както и езиковото и културното многообразие и грижите за уязвимите лица. Безопасната, сигурна, стабилна и устойчива архитектура представлява основата за доверието на потребителите на интернет. В същото време трябва да се поддържа иновационният потенциал на интернет с пълноценното участие на европейската интернет икономика въз основа на укрепен единен цифров пазар, свързан с останалия свят. Това изисква внимателно, но стриктно управление.
Сър Хауърд Стрингър е заемал високи позиции в Sony и CBS, а сега е директор в ВВС.
Публикуван е негов доклад за бъдещето на новините на обществената телевизия ВВС в цифровия свят и с перспектива 2022 г., когато аудиторията на ВВС се очаква да достигне 500 милиона.
За да е цифров лидер, ВВС трябва да мисли за характери индивидуалноств онлайн новините си, както и заусъвършенстване на техниките за споделянена съдържание, се казва в доклада.
В аудиоантологията за съвременна българска поезия “Представи”, Валентин Дишев чете стихотворението на Петър Чухов “Сбогуване с езика”:
Петър Чуховв “Кръстопът”.
Петър Чухов в DICTUM.
(първа публикация - в електронното мултимедийно списание за литература DICTUM)
