Treasury and PNNL threat data now available for Financial sector customers to secure applications

Post Syndicated from Alexandra Moraru original https://blog.cloudflare.com/threat-intelligence-custom-indicator-feeds-treasury-pnnl-partnerships


Following the White House’s National Cybersecurity Strategy, which underscores the importance of fostering public-private partnerships to enhance the security of critical sectors, Cloudflare is happy to announce a strategic partnership with the United States Department of the Treasury and the Department of Energy’s Pacific Northwest National Laboratory (PNNL) to create Custom Indicator Feeds that enable customers to integrate approved threat intelligence feeds directly into Cloudflare’s platform.

Our partnership with the Department of the Treasury and PNNL offers approved financial services institutions privileged access to threat data that was previously exclusive to the government. The feed, exposed as a Custom Indicator Feed, collects advanced insights from the Department of the Treasury and the federal government’s exclusive sources. Starting today, financial institutions can create DNS filtering policies through Cloudflare’s Gateway product that leverage threat data directly from these government bodies. These policies are crucial for protecting organizations from malicious links and phishing attempts specifically targeting the financial sector.

This initiative not only supports the federal effort to strengthen cybersecurity within critical infrastructure including the financial sector, for which the Treasury is the designated lead agency, but also contributes directly to the ongoing improvement of our shared security capabilities.

Why we partnered with the Department of the Treasury and PNNL

Our collaboration with the Department of the Treasury and PNNL is not just a partnership, it’s a solution to a critical problem where the financial industry requires timely access to actionable intelligence in order to address security threats. Our partnership is centered around the protection of critical financial institutions and their assets. By joining forces with partners like the Department of the Treasury and PNNL, we are empowering security teams to not just share information but to act swiftly and effectively against emerging threats.

Today, many security teams, both within the same industries and across sectors, exchange vital threat intelligence through out-of-band channels like email and Slack. However, the crucial step of integrating this information into an organization’s security systems often remains a manual, time-consuming process. By introducing Custom Indicator Feeds, we’re bridging this gap and enabling smaller security groups to automatically fortify their defenses.

The government possesses invaluable insights into emerging threats, and by joining forces, we will share this critical data with the private sector. Our combined efforts are aimed at fortifying the security of institutions in the financial sector, which is an enticing target for cybercriminals.

Introducing Custom Indicator Feeds

Custom Indicator Feeds enable customers to integrate approved threat intelligence feeds directly into Cloudflare’s platform. Our partners, including the Department of the Treasury and PNNL, contribute to these feeds, which are regularly updated with the latest threat indicators. Custom Indicator Feeds allows for the exchange of critical data on emerging cyber threats, ensuring that all parties involved can proactively defend against ransomware, phishing attacks, and other malicious activities.

In our context, a Custom Indicator Feed primarily consists of Indicators of Compromise (IoCs), which are detailed pieces of information that identify potentially malicious activity on a system or network. Examples of data included in these feeds are IP addresses, URLs, domain names, and hash values of suspicious or malicious files. Each entry is enriched with context to help security professionals understand the nature of the threat it poses, such as the type of malware associated, attack patterns, and threat severity levels.

Here’s a closer look at how these feeds are created and maintained: feeds are populated with IoCs such as domain names, IP addresses, and URL paths identified across the network environments monitored by entities like PNNL for the US Treasury, and these IoCs are initially detected by IDS (Intrusion Detection System) networks that continuously monitor for suspicious activities. Once an IoC is detected, it undergoes a rigorous verification process. Analysts at PNNL and other entities review each potential threat to confirm its malicious nature. This ensures that only verified malicious indicators are added to the feeds, reducing the risk of false positives affecting a feed subscriber’s security systems. After validation, these IoCs are added to their respective Custom Indicator Feed. These feeds are then made available to authorized users via Cloudflare’s secure API, ensuring that the data is both current and actionable.

Financial institutions that are granted access to this feed can integrate these indicators into their Cloudflare DNS filtering policies, enhancing their defense against specific threats identified by federal cybersecurity efforts.

Leveraging Custom Indicator Feeds for enhanced security

Once authorized for an indicator feed, you can create DNS filtering policies using the data provided by simply choosing the relevant feed when creating the policy. These policies then act as a protective shield, blocking access to malicious websites, phishing attempts, and other online threats.

The technical mechanics of Custom Indicator Feeds

Custom Indicator Feeds are structured around two distinct groups:

  • Custom Feed Providers (like Treasury and PNNL): Cloudflare provides an API for data providers to publish indicator feeds and periodically update them with new indicators. This process allows data providers an automated way to ensure that newly identified threats are swiftly added to their feed. The API also allows providers strict control over who has access to their feeds, allowing them to authorize Gateway accounts to use specific feeds.
  • Customer organizations using the Cloudflare Gateway: Once authorized for an indicator feed, organizations such as financial institutions can create DNS filtering policies using the data provided in the feed. Custom Indicator Feeds are incorporated into Cloudflare Gateway in much the same way as Cloudflare threat intelligence, the main difference being that the provider themselves must grant an account use of a specific indicator feed.

What’s next for Custom Indicator Feeds?

This is just the beginning of our work on Custom Indicator Feeds. We have ambitious plans for the future:

  • Expanding availability: We aim to make indicator feeds available for a broader range of our products, including WAF, Magic Firewall, and HTTP Gateway Policies.
  • Enhanced functionality: We plan to expand the Custom Indicator Feed functionality, allowing authorized accounts to access and download specific threat feed lists, giving organizations even more flexibility in their cybersecurity efforts.
  • Collaboration with other Feed Providers: We will facilitate multiple organizations to easily upload individual indicators to shared indicator feeds, creating a collaborative ecosystem for threat intelligence sharing.

How to get started

This offering is available at no cost to any financial institution recognized by the Department of Treasury and that currently uses Cloudflare Gateway. These institutions should reach out to Cloudflare for authorization to the Treasury-PNNL indicator feed.

For more information on how to consume or create your custom indicator feed, check out the developer documentation here.

Security updates for Friday

Post Syndicated from daroc original https://lwn.net/Articles/973206/

Security updates have been issued by AlmaLinux (container-tools:4.0, container-tools:rhel8, git-lfs, glibc, libxml2, nodejs:18, and nodejs:20), Debian (dav1d and libpgjava), Fedora (kernel and pypy), Red Hat (glibc and nodejs:16), SUSE (ffmpeg, ffmpeg-4, ghostscript, go1.21, go1.22, less, python-python-jose, python-Werkzeug, and sssd), and Ubuntu (fossil, glib2.0, and libspreadsheet-parsexlsx-perl).

За свободата и пристраст(е)ните медии

Post Syndicated from Емилия Милчева original https://www.toest.bg/za-svobodata-i-pristrast-e-nite-medii/

За свободата и пристраст(е)ните медии

Миналия юни знамето на британските либерални традиции „Гардиън“, медия на повече от 200 години, наложи пълна забрана на рекламите на хазарт. „Реклама на хазарт, поднесена в комбинация със спортна журналистика, може да има пагубни последици“, коментира известният спортен журналист на вестника Барни Рони, който обясни защо изданието казва „не“ на лесните пари. 

В най-гъсто населената провинция на Канада – Онтарио – действат правила, които забраняват рекламите за онлайн хазарт, включващи спортисти и известни личности, а наскоро организаторите на кампанията Ban Ads for Gambling поиска федералното правителство да забрани всякакви реклами на хазарт. В редица европейски страни също затягат режима за реклами на хазарта и особено на онлайн залаганията.

Фар на истината

Какъв му е проблемът на „Гардиън“, вероятно си мислят медийни собственици в България. От 1936 г. британският ежедневник е притежаван от „Скот Тръст“ – фонд, чиято цел е да осигури „постоянна финансова и редакторска независимост на „Гардиън“, избира главния редактор и контролира бизнес стратегията му. Но съвсем не е лесно да си еталон на качествена журналистика, защото – наред с принципите и задълженията – печеленето на обществено доверие включва и отговорност и грижа за общественото здраве. А това означава медиите да имат ясна за аудиторията редакционна политика, почтени журналисти и явни собственици, също и прозрачно финансиране. 

В един свой текст отпреди 13 години журналистът Самуел Леви, зам.-главен редактор на някогашния вестник „Демокрация“, обяснява така ролята на журналиста. 

[…] Един френски публицист – Серж Алами – беше нарекъл журналистите в страната си „кучета пазачи“. Самата комбинация в исторически план (в английския ѝ смисъл) има чисто позитивно значение – „пазач на нормите и морала“. Без съмнение, точно такава функция би следвало и да има журналистът. Но думата има и друг, пейоративен смисъл – „охранител, пазач“ – и е възможно да се мисли, че тяхната основна задача сега се свежда да отклоняване на вниманието от безумието на управниците (каквато е и сега същностната роля на четвъртата власт) и превръщането им в слуги на господстващите във властта.

Някой беше нарекъл журналистиката „фар на истината“. Значи, че професионалната почтеност не трябва да бъде компрометирана. Доверието на обществото е най-ценният актив за журналистите и ако бъде загубен, медията е просто канал за пропагандно и/или развлекателно съдържание. 

Но и в случаите на прозрачно финансиране би следвало да има хигиена, независимо от това, че най-големите телевизии и други медии, получаващи реклама от легалните хазартни оператори, са частни търговски дружества. Какво означава обаче фактът, че между 30 и 50% от техните приходи идват от реклами на хазарт (всъщност на бонуси и залагания, тъй като по закон пряката реклама на хазарт е забранена)? 

Хигиена на рекламата

Означава, че българските управляващи безотговорно са допуснали тази зависимост, без да въведат законови ограничения, както е в други европейски държави. Например: 

  • да бъде обозначена ясно и разбираемо като реклама на хазарт – защото често границите са размити; 
  • да не се представя по начин, който да предизвиква интереса на непълнолетни;
  • да не се излъчва или появява близо до съдържание, насочено към деца и младежи; 
  • да предупреждава, че има риск от зависимост; 
  • оператори, които не спазват правилата за реклама, да бъдат санкционирани със значителни глоби и дори загуба на лиценза за хазарт; 
  • също така да бъдат задължени медиите да включат съдържание, което да показва вредните последици от пристрастяването към хазарт. 

В Съединените щати например до 2013 г. проблемите с хазарта са дефинирани като разстройство на контрола на импулсите, но впоследствие петото издание на Диагностичния и статистически наръчник на психичните разстройства (DSM-5) ги класифицира като разстройство на пристрастяване. 

Българският проблем обаче е, че дори да има законово задължение, в него или ще има вратичка, или регулаторите, задължени да контролират, ще манкират, или пък санкциите ще бъдат символични. А и какво толкова, ще възразят някои, да не би чипс и храни от категорията „джънк“ да не вредят на здравето, но рекламите им не съобщават съдържанието на трансмазнини! Вредят, но и много по-често в медиите се говори за вредата от тях, а и те не пристрастяват така, както хазартната зависимост, която може да доведе до промени във функцията и структурата на мозъка. Може например да повлияе на фронталния кортекс, засягайки способността за вземане на решения, или да активира системата за възнаграждение на мозъка, като задейства освобождаването на допамин, и така човек да изпитва приятно вълнение и удоволствие. 

Ето че хазартът се оказва най-добрият способ за ощастливяване на българската нация, която всички класации показват като особено нещастна.

„Имало щастливи българи“

В разгара на „епидемията“ с търкането на лотарийни билети от обезумели и отчаяни да спечелят нещо хора по супермаркети, пейки и автобусни спирки, медиите не показваха такива картинки. Вместо тях излъчваха (рекламни) репортажи с „щастливци“ с огромни чекове в ръце и изписани върху тях суми, чийто живот е тръгнал по мед и масло с печалбата от лотарията. Това е неразделна част от съществуването на хазартния бизнес – да се покажат печелившите, иначе няма как да има доверие. (И при социализма във вестник „Спорт Тото“ пускаха снимки на спечелилите кола, апартамент или парична награда.)

Забележителното в ерата на божковите лотарии беше, че телевизиите показваха усмихнати доволни семейства, цели фамилии даже, които обясняваха какво ще направят с парите, паднали им от „игрите на щастието“. Така едно развлечение, една игра, каквато всъщност е хазартът, се превръща в ценност, идеал за щастлив живот и приоритет как да бъде живян. А след като спряха лотариите, започна агресивната реклама с известни личности на бонуси и залагания, продуцирана от следващите хазартни босове. Тя извира от медии, магистрали, метро, билбордове.

Трудно може да се открие в този период медийно съдържание, което да показва истории на разбити човешки съдби, хора, които съсипват собствения си живот и на близките си, тежкото лечение от зависимост като хазарта.  

Грижа за обществото? Едва ли

Законодателното решение, взето от 49-тия парламент в последните му дни, прекъсна финансирането на медиите с пари от хазарт и предизвика вълна от недоволство в най-големите телевизии и работодателски организации.

Предложението на ГЕРБ и ДПС беше подкрепено с абсолютно мнозинство от всички останали парламентарни групи, в т.ч. и от ПП–ДБ. Внасянето и приемането му на две четения протекоха в седмица, но никой не се заблуждава в добрите намерения на вносителите. Лотарийната индустрия на Васил Божков се разрасна с помощта на ДПС и ГЕРБ, а с нея и неконтролируемата реклама на хазарт в медиите и извън тях. През 2013 и 2014 г. промени в Закона за хазарта, внесени и обработени в движение от депутати от ДПС, БСП и ГЕРБ, позволиха на компаниите на Божков да избегнат плащане на стотици милиони на бюджета. 

Забраната обаче може изобщо да не задейства предвид ветото, което се очаква да наложи президентът Румен Радев, с аргумента, че законодателните промени са прибързани. Крайният срок за обявяването му е 15 дни от приемането на промените, което означава до 15 май. Ако държавният глава върне закона, 49-тият парламент ще трябва да се събере, за да го гласува – и ако депутатите пожелаят да затвърдят волята си, ще са необходими 121 гласа. В противен случай ветото остава, промените отпадат и рекламата на хазарта е неприкосновена, както и всички игрални зали и казина, защото настоящите промени вече задължават операторите да отварят такива само в селища с над 5000 жители.

За кого е държавната реклама

Рекламата на хазарт в медиите е част от голямата тема за финансирането им, която включва и въпроса кой получава реклама от държавата и общините. Това са публични средства, пари на данъкоплатците, насочени към т.нар. медийно обслужване, сиреч позитивен пиар, популяризиране на проекти и други инициативи на съответната институция. В интервю за „Капитал“ адвокат Александър Кашъмов, изпълнителен директор на фондация „Програма Достъп до информация“ и член на Комисията за журналистическа етика, предлага промяна в Закона за обществените поръчки, свързана с рекламата в медиите.

[…] необходима e нова промяна в този закон, която да отива по-далеч, като въведе задължение за публикуване на всички сключени договори за такива поръчки от съответните институции, включително и тези, които са само фактурирани като услуги.

Според адвокат Кашъмов „не би трябвало да се сключват подобни договори с медия, която не е декларирала данните си по реда на Закона за задължителното депозиране на печатни и други произведения – действителния собственик, управител, получено финансиране, сключени договори за медийни услуги с държавни и местни органи, партии и т.н.“ 

Политиците едва ли ще са петимни да откликнат на тази идея и да я облекат в законотворчество. Настоящото положение ги устройва. Днес може да забранят реклами – в случая на хазарта, утре може да пуснат няколко договора за медийно „служене“ (за средства по европейски програми) или да се договарят тайно за услуги в контролирана медийна среда. Опитомяването на медиите от „кучета пазачи“ на обществения интерес в любимите на властта пудели не е отсега.

В чия изгода е забраната за реклами на хазарта – ако остане, скоро ще е ясно. Но разговорът за независимостта на българските медии, която минава през финансирането им, никога не е късно да започне. За морала в журналистиката – също.

Make Architecture Great Again. Новият архитектурен популизъм (първа част)

Post Syndicated from Анета Василева original https://www.toest.bg/make-architecture-great-again-noviyat-arhitekturen-populizam-chast-1/

Make Architecture Great Again. Новият архитектурен популизъм (първа част)

От маргинален термин „популизъм“ се превърна в дума на годината през 2017 г. и вече е неделима част от ежедневието ни. Aрхитектурният популизъм не закъсня. У нас той надигна глава през 2019 г., някъде измежду активизирането на хоризонталното гражданско общество, избухването на социалните мрежи и тогавашните местни избори. Днес, пет години по-късно, той се развива в още по-сложна политическа (и геополитическа) обстановка и е все така видим. 

Но какво представлява популизмът днес?

Да се върнем малко назад. Лайпциг, 1989 г. Wir sind das Volk („Ние сме народът“) е политическият лозунг на протестите в ГДР срещу комунистическото правителство. В годините преди обединението на Германия призивът бързо прераства във Wir sind ein Volk („Ние сме един народ“). След 2014 г. обаче тази популярна фраза все по-често се използва в расистки, ислямофобски, крайнодесни и популистки по своята същност демонстрации срещу бежанци и джамии в Германия. 

Популисткият Zeitgeist

„Ние сме един народ“… „В името на народа“… Това са все фрази, които сякаш чуваме ежедневно – независимо дали в последната президентска предизборна кампания на Марин Льо Пен, или в българския парламент. Днес, когато думата „популизъм“ се появи в медиите, никой вече не ѝ дава обяснение, сякаш всеки знае какво е това. И уж всеки може да го опише – донякъде през примерите, станали шаблонни символи за съвременен популизъм – Брекзит, Тръмп, Унгария на Виктор Орбан или издигането на Жаир Болсонаро в Бразилия.

Всъщност най-влиятелното съвременно определение на думата дава един холандски политолог – Кас Муде, през далечната 2008 г., когато думата изобщо не се радва на такава популярност. Статията му е озаглавена точно така – „Популисткият дух на времето“. Популизмът, твърди Муде, е повече от обикновена демагогия, не е просто опортюнизъм, но не е и напълно формирана политическа идеология. Популизмът е „тънка идеология“ – това е изразът, който измисля Муде, – която се състои от много малко твърди убеждения. Първо, в нея най-важното разделение в обществото е между „хората“, „народа“, приемани за фундаментално добри, и елита, който фундаментално се приема за лош, корумпиран и напълно откъснат от ежедневния живот, от „народа“. 

По тази причина, всички популисти вярват, че политиката трябва да изразява „общата воля“ – желанията, споделяни от всички „обикновени“ хора. 

Ние срещу другите

Всъщност от маргинален термин през почти целия ХХ век „популизъм“ се превърна в дума на годината през 2017-та. Статията за популисткия цайтгайст на Муде вече е класика. Това, което той успешно прави като активен коментатор по темата вече 15 години, е да извади популизма единствено от крайнодясната му конотация („Подемос“ в Испания или СИРИЗА в Гърция също са популистки, макар и леви движения) и да посочи основната опасност – отношенията между „елита“ и „другите“. Популизмът се корени именно там и проблемът няма да бъде разрешен, ако „другите“ продължават да бъдат маргинализирани и презирани.

Забавно е определението на мексиканския политически теоретик Бенджамин Ардити. Той описва

популизма като пияния гост, дошъл на официалната вечеря на демокрацията,

който не дава и пет пари за правилата за добро поведение и приетата за правилна учтивост, следователно безцеремонно посочва грешки и прояви на лицемерие, които всички други в стаята са се съгласили да игнорират.

Отново Муде:

Популизмът е онзи, който задава правилните въпроси, но дава грешните отговори.

Архитектурният популизъм

И сега, след това дълго въведение, стигаме до основния ни въпрос: какво е архитектурният популизъм? 

Ще го илюстрирам с един нашумял пример, при това в развитие, чието начало е много назад във времето.

През февруари 2020 г. целият архитектурен свят и със сигурност американската му част настръхнаха, когато в американските медии изтече чернова на президентска заповед на Доналд Тръмп, станала известна като Making Federal Buildings Beautiful Again („Да направим федералните сгради отново красиви“). В нея се предлага пренаписване на правилата за нова архитектура на правителствените сгради в САЩ в посока „неокласицизъм като предпочитан стил“. Американският архитектурен институт и куп медии реагираха бурно срещу налагането на подобен единен стил, който според тях не отразява прогреса, нарушава свободата на творческата мисъл и изразяването и като цяло пречи на демокрацията. Шумът беше огромен и стигна даже до България.

През 2020 г. изтичаше последната година от мандата на Тръмп, през март светът „затвори“ заради пандемията от коронавирус и когато през декември президентът подписа тази заповед, шумът вече беше позатихнал. Всъщност тогава Тръмп подписа две заповеди – и двете доста спорни, естетически ориентирани и отчетливо антимодерни. Втората засягаше изкуството в правителствените сгради, което трябваше да изобразява „исторически значими американски личности или американски идеали“, и в нея изрично се подчертаваше, че това изобразяване не трябва да бъде в абстрактен или модернистичен стил.

След това Тръмп изгуби изборите, Байдън отмени и двете заповеди и историята сякаш заглъхна. Но всъщност изобщо не беше така. 

Нека сега отворим една историческа скоба и проследим що е то стил на правителствените сгради в САЩ, защо е възникнал, как е бил регулиран до този момент и какво общо има всичко това с архитектурния популизъм.

Америка и архитектурата на античен Рим

В края на XVIII век младата американска република има нужда от нова, достойна за нейния нов образ архитектура. Особено важен е видът на правителствените сгради. Измежду всички бащи основатели на новата американска нация – Джордж Вашингтон, Бенджамин Франклин и останалите –

най-загрижен за създаването на национална, „американска“ архитектура е Томас Джеферсън.

Той прави и най-много в тази посока – като губернатор на щата Вирджиния, като държавен секретар, а после и като трети американски президент. Джеферсън се обръща, разбира се, към класическата Античност. Тук среща пълното одобрение на своите съратници – хора на Просвещението. Идеалът е републикански (не императорски) Рим, където здравият морал е водещ във всички сфери на управлението. Американският Сенат иска да превъплъти римския Сенат. И затова новата Америка има нужда от римски архитектурни прецеденти.

Класическата архитектура визуално свързва новата република с античните предшественици на демокрацията.

Първата сграда на американския Конгрес например – Капитолият във Вашингтон – претърпява много трансформации до днешния си вид, но изворът на вдъхновението за създаването ѝ е един и той е очевиден – става дума, разбира се, за Пантеона в Рим.

В аналогичен неокласически стил е издържано и цялото централно ядро, както и градоустройството на Вашингтон – пример за осмислена и последователно наложена държавна политика, която остава валидна през следващия век и половина. Това е Америка на неокласическите публични и административни сгради, които властта приема за имиджови, изискани, правилни и елегантни. 

Но през 30-те години на ХХ век тези сгради се оказват притеснително подобни на архитектурата, която фаворизира Хитлер по същото време. А това постепенно започва да изглежда все по-нередно.

Америка и модернизмът

Нацистка Германия на Шпер и Хитлер официално приема, че не е редно публичната архитектура да бъде модерна. Тя трябва да представлява грандиозен неокласицизъм с колони, портици и множество аналогии с Римската империя и Античността. 

Съответно Съединените щати трябва да отговорят. Те приемат прогонените от Третия райх немски архитекти емигранти от „Баухаус“, а заедно с тях и

модернизма – като мощно оръжие срещу официалния архитектурен стил на нацистка Германия,

а по-късно, през Студената война – и срещу еклектичния, обърнат към миналото социалистически реализъм на Сталин. 

Очевидно е, че модернизмът е стилът на следвоенната епоха, включително и на нейния символ – централата на ООН в Ню Йорк, завършена през 1951 г. Затова, естествено, и архитектурата на правителствените сгради в САЩ се променя – при това регламентирано.

През 1961 г. американският президент Джон Кенеди казва:

Ние не имитираме, защото трябва да бъдем модел за останалите.

Той основава комитет начело с бъдещия сенатор и дипломат Даниел Патрик Мойнихан. Така през 1962 г. влиза в сила един важен документ, озаглавен „Водещи принципи на федералната архитектура“, който не само отхвърля неокласицизма като водещ стил за федералните сгради дори във Вашингтон, но също така постановява, че налагането на официален, единен стил по принцип трябва да се избягва. Дизайнът и дизайнерските решения следва да идват от архитектурната професия към правителството, а не обратно. 

Резултат от точно този документ и свободата, която той дава, са всички сгради, които Тръмп и останалите защитници на неокласицизма обичат да мразят. Всъщност немалко хора ги мразят. 

„Най-грозните“ сгради

60-те и 70-те години на ХХ век са време на архитектурен брутализъм в САЩ и правителствените сгради от този период отразяват напълно духа на епохата – с всички добри и лоши нейни страни. Централата на ФБР например обичайно оглавява популярните списъци с най-грозните сгради във Вашингтон и Америка, но същевременно и всички архитектурни гидове с бруталистични сгради икони на града. 

През 90-те години умората от модернизма и брутализма е осезаема и американската държавна администрация се опитва да пребори монотонността на архитектурата на правителствените сгради с нова инициатива – т.нар. Design Excellence Program от 1994 г. – с цел да надгради принципите на Мойнихан и другите идеалисти от епохата на Кенеди с експерименти в дизайна. Построени са над 150 сгради – някои може би наистина отлични, други – далеч не толкова. Обществото, разбира се, отново недоволства. 

Сградите, проектирани по тази програма, се оказват не по-малко мразени от кутиите от стъкло и бетон от предишните десетилетия. И трябва да признаем, че критиците на съвременната правителствена архитектура в САЩ, включително подкрепящите написаното в онази заповед на Тръмп, имат право до известна степен. В Америка действително има много, истински ужасни правителствени сгради. И те няма как да не изгубят точки пред класическата монументалност на сгради като Капитолия във Вашингтон. 

Затова не е учудващо, че през 2023 г. Марко Рубио, добре известният републикански сенатор от Флорида, внася за разглеждане в Сената нов законопроект – Beautifying Federal Civic Architecture Act, който отново постановява, че за своите сгради правителството следва да предпочита архитектурни проекти, които са вдъхновени от формите, принципите и изобщо от архитектурата на антична Гърция и Рим.

Защо? Ами защото хората просто не харесват другите сгради!

Близки до Тръмп неправителствени организации като National Civic Art Society доказват това със социологическо проучване още през 2020 г.: 72% от американците предпочитат „традиционна“, а не „модерна“ архитектура. Показателно е, че предпочитанията към „традиционна архитектура“ – в която авторите на изследването включват не само неокласицизъм, но и неоготика, неоколониален стил и други неостилове от XIX и началото на XX век – са водещи във всички възрастови групи, независимо коя партия подкрепят, каква раса са, от кой регион, с какво образование и с какви доходи. Такава е „волята на народа“, какво може да се направи?

Но да си припомним как действа популизмът – той задава верните въпроси, но им дава грешни отговори. 

Вашингтон на пръв поглед е еклектичен микс от стилове, но всъщност неговият брутализъм се съобразява с класическите образци по блестящ начин – и като обеми, и като ритъм, пропорции, материали. „Най-грозната сграда в САЩ“ – сградата на ФБР – е всъщност контрастен, но хармоничен обем в разнородния градски фронт.

Вашингтонското метро, пак брутализъм, пак от 70-те години на ХХ век, е всъщност обяснение в любов към собствения си контекст – макар и с така мразения видим бетон. Никой детайл тук не е пренебрегнат като дребен и незначителен. Всички авторитети на следвоенния американски дизайн са намесени, за да се получи този резултат. Буншафт казва, че парапетите трябва да са като излети, подобно на скулптура на Хенри Мур. Сасаки иска хората да бъдат защитени от визуалното замърсяване на рекламите. Светлината е, за да осветява; всяка повърхност и всеки материал са обмислени. Нищо не е прекалено.

Вашингтонското метро е безспорен архитектурен шедьовър – с прекрасните си пространства и изключителна работа със светлината

(архитектът Хари Уийз работи специално със светлинния дизайнер Бил Лам върху системата от индиректно осветление в станциите). С чудесната система за ориентиране, дизайн и навигация (разработена от легендарния модернистичен графичен дизайнер Масимо Винели). И с тази визуално обсебваща, но незабравима игра на античния касетиран таван с видимия бетон на епохата.

Може ли закон да регламентира добрата архитектура?

Независимо дали я наричаме „красива“, или „модерна“. Опасявам се, че не. Това наистина е архитектурен популизъм. Могат ли елитите да променят рязко масовото обществено мнение и масовия естетически визуален вкус? Опасявам се, че също не. Поне не радикално и не изведнъж. Макар че именно американските елити от следвоенната епоха поръчват и довеждат докрай проекти като вашингтонското метро именно защото модернизмът иска да възпитава добър масов вкус – насочен към бъдещето, а не към миналото.

(Очаквайте продължение на темата с анализ на архитектурния популизъм в България.)

Achieve peak performance and boost scalability using multiple Amazon Redshift serverless workgroups and Network Load Balancer

Post Syndicated from Ricardo Serafim original https://aws.amazon.com/blogs/big-data/achieve-peak-performance-and-boost-scalability-using-multiple-amazon-redshift-serverless-workgroups-and-network-load-balancer/

As data analytics use cases grow, factors of scalability and concurrency become crucial for businesses. Your analytic solution architecture should be able to handle large data volumes at high concurrency and without compromising speed, thereby delivering a scalable high-performance analytics environment.

Amazon Redshift Serverless provides a fully managed, petabyte-scale, auto scaling cloud data warehouse to support high-concurrency analytics. It offers data analysts, developers, and scientists a fast, flexible analytic environment to gain insights from their data with optimal price-performance. Redshift Serverless auto scales during usage spikes, enabling enterprises to cost-effectively help meet changing business demands. You can benefit from this simplicity without changing your existing analytics and business intelligence (BI) applications.

To help meet demanding performance needs like high concurrency, usage spikes, and fast query response times while optimizing costs, this post proposes using Redshift Serverless. The proposed solution aims to address three key performance requirements:

  • Support thousands of concurrent connections with high availability by using multiple Redshift Serverless endpoints behind a Network Load Balancer
  • Accommodate hundreds of concurrent queries with low-latency service level agreements through scalable and distributed workgroups
  • Enable subsecond response times for short queries against large datasets using the fast query processing of Amazon Redshift

The suggested architecture uses multiple Redshift Serverless endpoints accessed through a single Network Load Balancer client endpoint. The Network Load Balancer evenly distributes incoming requests across workgroups. This improves performance and reduces latency by scaling out resources to meet high throughput and low latency demands.

Solution overview

The following diagram outlines a Redshift Serverless architecture with multiple Amazon Redshift managed VPC endpoints behind a Network Load Balancer.

The following are the main components of this architecture:

  • Amazon Redshift data sharing – This allows you to securely share live data across Redshift clusters, workgroups, AWS accounts, and AWS Regions without manually moving or copying the data. Users can see up-to-date and consistent information in Amazon Redshift as soon as it’s updated. With Amazon Redshift data sharing, the ingestion can be done at the producer or consumer endpoint, allowing the other consumer endpoints to read and write the same data and thereby enabling horizontal scaling.
  • Network Load Balancer – This serves as the single point of contact for clients. The load balancer distributes incoming traffic across multiple targets, such as Redshift Serverless managed VPC endpoints. This increases the availability, scalability, and performance of your application. You can add one or more listeners to your load balancer. A listener checks for connection requests from clients, using the protocol and port that you configure, and forwards requests to a target group. A target group routes requests to one or more registered targets, such as Redshift Serverless managed VPC endpoints, using the protocol and the port number that you specify.
  • VPC – Redshift Serverless is provisioned in a VPC. By creating a Redshift managed VPC endpoint, you enable private access to Redshift Serverless from applications in another VPC. This design allows you to scale by having multiple VPCs as needed. The VPC endpoint provides a dedicate private IP for each Redshift Serverless workgroup to be used as the target groups on the Network Load Balancer.

Create an Amazon Redshift managed VPC endpoint

Complete the following steps to create the Amazon Redshift managed VPC endpoint:

  1. On the Redshift Serverless console, choose Workgroup configuration in the navigation pane.
  2. Choose a workgroup from the list.
  3. On the Data access tab, in the Redshift managed VPC endpoints section, choose Create endpoint.
  4. Enter the endpoint name. Create a name that is meaningful for your organization.
  5. The AWS account ID will be populated. This is your 12-digit account ID.
  6. Choose a VPC where the endpoint will be created.
  7. Choose a subnet ID. In the most common use case, this is a subnet where you have a client that you want to connect to your Redshift Serverless instance.
  8. Choose which VPC security groups to add. Each security group acts as a virtual firewall to control inbound and outbound traffic to resources protected by the security group, such as specific virtual desktop instances.

The following screenshot shows an example of this workgroup. Note down the IP address to use during the creation of the target group.

Repeat these steps to create all your Redshift Serverless workgroups.

Add VPC endpoints for the target group for the Network Load Balancer

To add these VPC endpoints to the target group for the Network Load Balancer using Amazon Elastic Compute Cloud (Amazon EC2), complete the following steps:

  1. On the Amazon EC2 console, choose Target groups under Load Balancing in the navigation pane.
  2. Choose Create target group.
  3. For Choose a target type, select Instances to register targets by instance ID, or select IP addresses to register targets by IP address.
  4. For Target group name, enter a name for the target group.
  5. For Protocol, choose TCP or TCP_UDP.
  6. For Port, use 5439 (Amazon Redshift port).
  7. For IP address type, choose IPv4 or IPv6. This option is available only if the target type is Instances or IP addresses and the protocol is TCP or TLS.
  8. You must associate an IPv6 target group with a dual-stack load balancer. All targets in the target group must have the same IP address type. You can’t change the IP address type of a target group after you create it.
  9. For VPC, choose the VPC with the targets to register.
  10. Leave the default selections for the Health checks section, Attributes section, and Tags section.

Create a load balancer

After you create the target group, you can create your load balancer. We recommend using port 5439 (Amazon Redshift default port) for it.

The Network Load Balancer serves as a single-access endpoint and will be used on connections to reach Amazon Redshift. This allows you to add more Redshift Serverless workgroups and increase the concurrency transparently.

Testing the solution

We tested this architecture to run three BI reports with the TPC-DS dataset (cloud benchmark dataset) as our data. Amazon Redshift includes this dataset for free when you choose to load sample data (sample_data_dev database). The installation also provides the queries to test the setup.

Among all the queries from TPC-DS benchmark, we chose the following three to use as our report queries. We changed the first two report queries to use a CREATE TABLE AS SELECT (CTAS) query on temporary tables instead of the WITH clause to emulate options you can see on a typical BI tool. For our testing, we also disabled the result cache to make sure that Amazon Redshift would run the queries every time.

The set of queries contains the creation of temporary tables, a join between those tables, and the cleanup. The cleanup step drops tables. This isn’t needed because they’re deleted at the end of the session, but this aims to simulate all that the BI tool does.

We used Apache JMETER to simulate clients invoking the requests. To learn more about how to use and configure Apache JMETER with Amazon Redshift, refer to Building high-quality benchmark tests for Amazon Redshift using Apache JMeter.

For the tests, we used the following configurations:

  • Test 1 – A single 96 RPU Redshift Serverless vs. three workgroups at 32 RPU each
  • Test 2 – A single 48 RPU Redshift Serverless vs. three workgroups at 16 RPU each

We tested three reports by spawning 100 sessions per report (300 total). There were 14 statements across the three reports (4,200 total). All sessions were triggered simultaneously.

The following table summarizes the tables used in the test.

Table Name Row Count
Catalog_page 93,744
Catalog_sales 23,064,768
Customer_address 50,000
Customer 100,000
Date_dim 73,049
Item 144,000
Promotion 2,400
Store_returns 4,600,224
Store_sales 46,086,464
Store 96
Web_returns 1,148,208
Web_sales 11,510,144
Web_site 240

Some tables were modified by ingesting more data than what the TPC-DS schema offers on Amazon Redshift. Data was reinserted on the table to increase the size.

Test results

The following table summarizes our test results.

TEST 1 . Time Consumed Number of Queries Cost Max Scaled RPU Performance
Single: 96 RPUs 0:02:06 2,100 $6 279 Base
Parallel: 3x 32 RPUs 0:01:06 2,100 $1.20 96 48.03%
Parallel 1 (32 RPU) 0:01:03 688 $0.40 32 50.10%
Parallel 2 (32 RPU) 0:01:03 703 $0.40 32 50.13%
Parallel 3 (32 RPU) 0:01:06 709 $0.40 32 48.03%
TEST 2 . Time Consumed Number of Queries Cost Max Scaled RPU Performance
Single: 48 RPUs 0:01:55 2,100 $3.30 168 Base
Parallel: 3x 16 RPUs 0:01:47 2,100 $1.90 96 6.77%
Parallel 1 (16 RPU) 0:01:47 712 $0.70 36 6.77%
Parallel 2 (16 RPU) 0:01:44 696 $0.50 25 9.13%
Parallel 3 (16 RPU) 0:01:46 692 $0.70 35 7.79%

The preceding table shows that the parallel setup was faster than the single at a lower cost. Also, in our tests, even though Test 1 had double the capacity of Test 2 for the parallel setup, the cost was still 36% lower and the speed was 39% faster. Based on these results, we can conclude that for workloads that have high throughput (I/O), low latency, and high concurrency requirements, this architecture is cost-efficient and performant. Refer to the AWS Pricing Cost Calculator for Network Load Balancer and VPC endpoints pricing.

Redshift Serverless automatically scales the capacity to deliver optimal performance during periods of peak workloads including spikes in concurrency of the workload. This is evident from the maximum scaled RPU results in the preceding table.

Recently released features of Redshift Serverless such as MaxRPU and AI-driven scaling were not used for this test. These new features can increase the price-performance of the workload even further.

We recommend enabling cross-zone load balancing on the Network Load Balancer because it distributes requests from clients to registered targets. Enabling cross-zone load balancing will help balance the requests among the Redshift Serverless managed VPC endpoints irrespective of the Availability Zone they are configured in. Also, if the Network Load Balancer receives traffic from only one server (same IP), you should always use an odd number of Redshift Serverless managed VPC endpoints behind the Network Load Balancer.

Conclusion

In this post, we discussed a scalable architecture that increases the throughput of Redshift Serverless in low latency, high concurrency scenarios. Having multiple Redshift Serverless workgroups behind a Network Load Balancer can deliver a horizontally scalable solution at the best price-performance.

Additionally, Redshift Serverless uses AI techniques (currently in preview) to scale automatically with workload changes across all key dimensions—such as data volume changes, concurrent users, and query complexity—to meet and maintain your price-performance targets.

We hope this post provides you with valuable guidance. We welcome any thoughts or questions in the comments section.


About the Authors

Ricardo Serafim is a Senior Analytics Specialist Solutions Architect at AWS.

Harshida Patel is a Analytics Specialist Principal Solutions Architect, with AWS.

Urvish Shah is a Senior Database Engineer at Amazon Redshift. He has more than a decade of experience working on databases, data warehousing and in analytics space. Outside of work, he enjoys cooking, travelling and spending time with his daughter.

Amol Gaikaiwari is a Sr. Redshift Specialist focused on helping customers realize their business outcomes with optimal Redshift price-performance. He loves to simplify data pipelines and enhance capabilities through adoption of latest Redshift features.

How Criminals Are Using Generative AI

Post Syndicated from Bruce Schneier original https://www.schneier.com/blog/archives/2024/05/how-criminals-are-using-generative-ai.html

There’s a new report on how criminals are using generative AI tools:

Key Takeaways:

  • Adoption rates of AI technologies among criminals lag behind the rates of their industry counterparts because of the evolving nature of cybercrime.
  • Compared to last year, criminals seem to have abandoned any attempt at training real criminal large language models (LLMs). Instead, they are jailbreaking existing ones.
  • We are finally seeing the emergence of actual criminal deepfake services, with some bypassing user verification used in financial services.

AI Video Understanding in Your Apps with Twelve Labs and Backblaze

Post Syndicated from Pat Patterson original https://backblaze.com/blog/ai-video-understanding-in-your-apps-with-twelve-labs-and-backblaze/

A decorative header depicting several screens with video editing tasks and a cloud with the Backblaze logo on it.

Over the past few years, since long before the recent large language model (LLM) revolution, we’ve benefited not only from the ability of AI models to transcribe audio to text, but also to automatically tag video files according to their content. Media asset management (MAM) software—such as Backlight iconik and Axle.ai (both Backblaze Partners, by the way)—allows media professionals to quickly locate footage by searching for combinations of tags. For example, “red car”, will return not only a list of video files containing red cars, but also the timecodes pinpointing the appearance of the red car in each clip.

San Francisco startup Twelve Labs has created a video understanding platform that allows any developer to build this kind of functionality, and more, into their app via a straightforward RESTful API. 

In preparation for our webinar with Twelve Labs last month, I created a web app to show how to integrate Twelve Labs with Backblaze B2 for storing video. The complete sample app is available as open source at GitHub; in this blog post, I’ll provide a brief description of the Twelve Labs platform, explain how presigned URLs allow temporary access to files in a private bucket, and then share the key elements of the sample app. If you just want a high level understanding of the integration, read on, and feel free to skip the technical details!

The Twelve Labs Video Understanding Platform

The core of the Twelve Labs platform is a foundation model that operates across the visual, audio, and text modes of video content, allowing multimodal video understanding. When you submit a video using the Twelve Labs Task API, the platform generates a compact numerical representation of the video content, termed an embedding, that identifies entities, actions, patterns, movements, objects, scenes, other elements of the video, and their interrelationships. The embedding contains everything the Twelve Labs platform needs to do its work—after the initial scan, the platform no longer needs access to the original video content. As each video is scanned into the platform, its embedding is added to an index, so this scanning process is often referred to as indexing.

As part of the indexing process, the platform extracts a standard set of data from each video: a thumbnail image, a transcript of any spoken content, any text that appears on screen, and a list of brand logos, all annotated with timecodes locating them on the video’s timeline, and all accessible via the Twelve Labs Index API.

You can have the platform create a title and summary, and even prompt the model to describe the video, via Twelve Labs’ Generate API. For example, I indexed an eight-minute video that explains how to back up a Synology NAS to Backblaze B2, then prompted the Generate API, “What are the two Synology applications mentioned in the video?” This was the first sentence of the resulting text:

The two Synology applications mentioned throughout the video are “Synology Hyper Backup” and “Synology Cloud Sync.”

The remainder of the response is a brief summary of the two applications and how they differ; here’s the full text. Although it does have that “AI flavor” as you read it, it’s clear and accurate. I must admit, I was quite impressed!

You can define a taxonomy for your videos via the Classify API. Submit a one- or two-level classification schema and a set of video IDs, and the platform will assign each video to a category.

Rounding up this quick tour of the Twelve Labs platform, the Search API, as its name suggests, allows you to search the indexed videos. As well as a search query, you must specify a set of content sources: any combination of visual, conversation, text in video, or logos. Each search result includes timecodes for its start and end.

Now you understand the basic capabilities of the Twelve Labs platform, let’s look at how you can integrate it with Backblaze B2.

Allowing Temporary Access to Files in a Private Backblaze B2 Bucket

A key feature of the sample app is that it uploads videos to a private Backblaze B2 Bucket, where they are only accessible to authorized users. Twelve Labs’ API allows you to submit a video for indexing by POSTing a JSON payload including the video’s URL to its Task API. This is straightforward for video files in a public bucket, but how do we allow the Twelve Labs platform to read files from a private bucket?

One way would be to create an application key with capabilities to read files from the private bucket and share it with the Twelve Labs platform. The main drawback to this approach is that the platform currently lacks the ability to sign requests for files from a private bucket.

Since Twelve Labs only needs to read the video file when we submit it for indexing, we can send it a presigned URL for the video file. As well as the usual Backblaze B2 endpoint, bucket name, and object key (path and filename), a presigned URL includes query parameters containing data such as the time when the URL was created, its validity period in seconds, an application key ID (or access key ID, in S3 terminology), and a signature created with the corresponding application key (secret access key). Here’s an example, with line breaks added for clarity:

https://s3.us-west-004.backblazeb2.com/mybucket/image.jpeg
?X-Amz-Algorithm=AWS4-HMAC-SHA256
&X-Amz-Credential=00415f935c00000000aa%2F20240423%2Fus-west-004%2Fs3%2Faws4_request
&X-Amz-Date=20240423T222652Z
&X-Amz-Expires=3600
&X-Amz-SignedHeaders=host
&X-Amz-Signature=23ade1...3ca1eb

This URL was created at 22:26:52 UTC on 04/23/2024, and was valid for one hour (3600 seconds). The signature is 64 hex characters. Changing any part of the URL, for example, the X-Amz-Date parameter, invalidates the signature, resulting in an HTTP 403 Forbidden error when you try to use it, with a corresponding message in the response payload:

<?xml version="1.0" encoding="UTF-8" standalone="yes"?>
<Error>
    <Code>SignatureDoesNotMatch</Code>
    <Message>Signature validation failed</Message>
</Error>

Attempting to use the presigned URL after it expires yields HTTP 401 Unauthorized with a message such as:

<?xml version="1.0" encoding="UTF-8" standalone="yes"?>
<Error>
    <Code>UnauthorizedAccess</Code>
    <Message>Request has expired given timestamp: '20240423T222652Z' and expiration: 3600</Message>
</Error>

You can create presigned URLs with any of the AWS SDKs or the AWS CLI. For example, with the CLI:

% aws s3 presign s3://mybucket/image.jpeg --expires-in 600 
https://s3.us-west-004.backblazeb2.com/mybucket/image.jpeg?X-Amz...

Presigned URLs are useful whenever you want to provide temporary access to a file in a private bucket without having to share an application key for a client app to sign the request itself. The sample app also uses them when rendering HTML web pages. For example, all of the thumbnail images are retrieved by the user’s browser via presigned URLs.

Note that presigned URLs are a feature of Backblaze B2’s S3 Compatible API. Creating a presigned URL is an offline operation and does not consume any API calls. We recommend you use presigned URLs rather than the b2_get_download_authorization B2 Native API operation, since the latter is a class C API call.

Inside the Backblaze B2 + Twelve Labs Media Asset Management Example

The sample app is written in Python, using JavaScript for its front end, the Django web framework for its backend, the Huey task queue for managing long-running tasks, and the Twelve Labs Python SDK to interact with the Twelve Labs platform. A simple web UI allows the user to upload videos to the private bucket, browse uploaded videos, submit them for indexing, view the resulting transcription, logos, etc., and search the indexed videos.

Most of the application code is concerned with rendering the web UI; very little code is required to interact with Twelve Labs.

Configuration

The Django settings.py file defines a constant for the Twelve Labs index ID and creates an SDK client object using the Twelve Labs API key. Note that the app reads the index ID and API key from environment variables, rather than including the values in the source code. Externalizing the index ID as an environment variable allows more flexibility in deployment while, of course, you should never include secrets such as passwords or API keys in source code!

TWELVE_LABS_INDEX_ID = os.environ['TWELVE_LABS_INDEX_ID']
TWELVE_LABS_CLIENT = TwelveLabs(api_key=os.environ['TWELVE_LABS_API_KEY'])

Startup

When the web application starts, it validates the index ID and API key by retrieving details of the index. This is the relevant code, in apps.py:

index = TWELVE_LABS_CLIENT.index.retrieve(TWELVE_LABS_INDEX_ID)

If this API call fails, then the app prints a suitable diagnostic message identifying the issue.

Indexing

When a web application needs to perform an action that takes more than a few seconds to complete—for example—indexing a set of videos, it typically starts a background task to do the work, and returns an appropriate response to the user. The sample app follows this pattern: when the user selects one or more videos and hits the Index button, the web app starts a Huey task, do_video_indexing(), passing the IDs of the selected videos, and returns the IDs to the JavaScript front end. The front end can then show that the indexing tasks have started, and poll for their current status.

Here’s the code, in tasks.py, for submitting the videos for indexing.

# Create a task for each video we want to index
for video_task in video_tasks:
    task = TWELVE_LABS_CLIENT.task.create(
        TWELVE_LABS_INDEX_ID,
        url=default_storage.url(video_task['video']),
        disable_video_stream=True
    )
    print(f'Created task: {task}')
    video_task['task_id'] = task.id

Notice the call to default_storage.url(). This function, implemented by the django-storages library, takes as its argument the path to the video file, returning the presigned URL. The default expiry period is one hour.

Once the videos have been submitted, do_video_indexing() polls for the status of each indexing task until all are complete. Most of the code is concerned with minimizing the number of calls to the API, and saving status to the app’s database; getting the status of a task is simple:

task = TWELVE_LABS_CLIENT.task.retrieve(video_task['task_id'])

The task object’s status attribute is a string with a value such as validating, indexing, or ready. When the task reaches the ready status, the task object also includes a video_id attribute, uniquely identifying the video within the Twelve Labs platform. At this point, do_video_indexing() calls a helper function that retrieves the thumbnail, transcript, text, and logos and stores them in Backblaze B2.

Retrieving Video Data

Here’s the call to retrieve the thumbnail:

thumbnail_url = TWELVE_LABS_CLIENT.index.video.thumbnail(TWELVE_LABS_INDEX_ID, video.video_id)

The helper function creates a path for the thumbnail file from the video ID and the file extension in the returned URL, and saves the thumbnail to Backblaze B2:

default_storage.save(thumbnail_path, urlopen(thumbnail_url))

Again, django-storages is doing the heavy lifting. We use urlopen(), from the urllib.request module, to open the thumbnail URL, providing default_storage.save() with a file-like object from which it can read the thumbnail data.

The calls to retrieve transcript, text, and logo data have a slightly different form, for example:

video_data = TWELVE_LABS_CLIENT.index.video.transcription(TWELVE_LABS_INDEX_ID, video.video_id)

Each call returns a list of VideoValue objects, each VideoValue object comprising a start and end timecode (in seconds) and a value specific to the type of data; for example, a fragment of the transcription. We serialize each list to JSON and save it as a file in Backblaze B2.

When the user navigates to the detail page for a video, JavaScript reads each dataset from Backblaze B2 and renders it into the page, allowing the user to easily navigate to any of the data items.

Searching the Index

When the user enters a query and hits the search button, the backend calls the Twelve Labs Search API, passing the query text, and requesting results for all four sources of information. We set group_by to video since we want to show the results by video, and set the confidence threshold to medium to improve the relevance of the results. From VideoSearchView in views.py:

results = TWELVE_LABS_CLIENT.search.query(
    TWELVE_LABS_INDEX_ID,
    query,
    ["visual", "conversation", "text_in_video", "logo"],
    group_by="video",
    threshold="medium"
)

By default, the query() call returns a page of 10 results in result.data, so we loop through the pages using next(result) to fetch pages of search results as necessary. Each individual search result includes start and end timecodes, confidence, and the type of match (visual, conversation, text, or logo).

In the web UI, the user can click through to the results for a given video, then click an individual search result to view the matching video clip.

Getting Started with Backblaze B2 and Twelve Labs

Backblaze B2 Cloud Storage is a great choice for storing video to index with Twelve Labs; free egress each month for up to three times the amount of data you’re storing means that you can submit your entire video library to the Twelve Labs platform without worrying about data transfer charges, and unlimited free egress to our CDN partners reduces the costs of distributing video content to end users.

Click here to create a Backblaze B2 account, if you don’t already have one. Your first 10GB of storage is free, no credit card required. If you’re an enterprise that wants to run a larger proof of concept, you can always reach out to our Sales Team. You don’t need to write any code to upload video files or create presigned URLs, and you can use the Backblaze web UI to upload files up to 500MB, or any of a wide variety of tools to upload files up to 10TB, including the AWS CLI, rclone and Cyberduck. Select S3 as the protocol to be able to create presigned URLs.

Similarly, click here to sign up for Twelve Labs’ Free plan. With it, you can index up to 600 minutes of video, again, no credit card required. Python and Node.js developers can use one of the Twelve Labs SDKs, while the Twelve Labs API documentation includes code examples for a wide range of other programming languages.

The post AI Video Understanding in Your Apps with Twelve Labs and Backblaze appeared first on Backblaze Blog | Cloud Storage & Cloud Backup

Use AWS Glue Data Catalog views to analyze data

Post Syndicated from Leonardo Gomez original https://aws.amazon.com/blogs/big-data/use-aws-glue-data-catalog-views-to-analyze-data/

In this post, we show you how to use the new views feature the AWS Glue Data Catalog. SQL views are a powerful object used across relational databases. You can use views to decrease the time to insights of data by tailoring the data that is queried. Additionally, you can use the power of SQL in a view to express complex boundaries in data across multiple tables that can’t be expressed with simpler permissions. Data lakes provide customers the flexibility required to derive useful insights from data across many sources and many use cases. Data consumers can consume data where they need to across lines of business, increasing the velocity of insights generation.

Customers use many different processing engines in their data lakes, each of which have their own version of views with different capabilities. The AWS Glue Data Catalog and AWS Lake Formation provide a central location to manage your data across data lake engines.

AWS Glue has released a new feature, SQL views, which allows you to manage a single view object in the Data Catalog that can be queried from SQL engines. You can create a single view object with a different SQL version for each engine you want to query, such as Amazon Athena, Amazon Redshift, and Spark SQL on Amazon EMR. You can then manage access to these resources using the same Lake Formation permissions that are used to control tables in the data lake.

Solution overview

For this post, we use the Women’s E-Commerce Clothing Review. The objective is to create views in the Data Catalog so you can create a single common view schema and metadata object to use across engines (in this case, Athena). Doing so lets you use the same views across your data lakes to fit your use case. We create a view to mask the customer_id column in this dataset, then we will share this view to another user so that they can query this masked view.

Prerequisites

Before you can create a view in the AWS Glue Data Catalog, make sure that you have an AWS Identity and Access Management (IAM) role with the following configuration:

  • The following trust policy:
    {
      "Version": "2012-10-17",
      "Statement": [
        {
          "Effect": "Allow",
          "Principal": {
            "Service": [
               "glue.amazonaws.com",
               "lakeformation.amazonaws.com"
            ]
          },
          "Action": "sts:AssumeRole"
        }
      ]
    }

  • The following pass role policy:
    {
      "Version": "2012-10-17",
      "Statement": [
        {
          "Sid": "Stmt1",
          "Action": [
            "iam:PassRole"
          ],
          "Effect": "Allow",
          "Resource": "*",
          "Condition": {
             "StringEquals": {
               "iam:PassedToService": [
                 "glue.amazonaws.com",
                 "lakeformation.amazonaws.com"
               ]
             }
           }
         }
       ]
    }

  • Finally, you will also need the following permissions:
    • "Glue:GetDatabase",
    • "Glue:GetDatabases",
    • "Glue:CreateTable",
    • "Glue:GetTable",
    • "Glue:UpdateTable",
    • "Glue:DeleteTable",
    • "Glue:GetTables",
    • "Glue:SearchTables",
    • "Glue:BatchGetPartition",
    • "Glue:GetPartitions",
    • "Glue:GetPartition",
    • "Glue:GetTableVersion",
    • "Glue:GetTableVersions"

Run the AWS CloudFormation template

You can deploy the AWS CloudFormation template glueviewsblog.yaml to create the Lake Formation database and table. The dataset will be loaded into an Amazon Simple Storage Service (Amazon S3) bucket.

For step-by-step instructions, refer to Creating a stack on the AWS CloudFormation console.

When the stack is complete, you can see a table called clothing_parquet on the Lake Formation console, as shown in the following screenshot.

Create a view on the Athena console

Now that you have your Lake Formation managed table, you can open the Athena console and create a Data Catalog view. Complete the following steps:

  1. In the Athena query editor, run the following query on the Parquet dataset:
SELECT * FROM "clothing_reviews"."clothing_parquet" limit 10;

In the query results, the customer_id column is currently visible.

Next, you create a view called hidden_customerID and mask the customer_id column.

  1. Create a view called hidden_customerID:
CREATE PROTECTED MULTI DIALECT VIEW clothing_reviews.hidden_customerid SECURITY DEFINER AS 
SELECT * FROM clothing_reviews.clothing_parquet

In the following screenshot, you can see a view called hidden_customerID was successfully created.

  1. Run the following query to mask the first four characters of the customer_id column for the newly generated view:
ALTER VIEW clothing_reviews.hidden_customerid UPDATE DIALECT AS
SELECT '****' || substring(customer_id, 4) as customer_id,clothing_id,age,title,review_text,rating,recommend_ind,positive_feedback,division_name,department_name,class_name 
FROM clothing_reviews.clothing_parquet

You can see in the following screenshot that the view hidden_customerID has the customer_id column’s first four characters masked.

The original table clothing_parquet remains the same unmasked.

Grant access of the view to another user to query

Data Catalog views allow you to use Lake Formation to control access. In this step, you grant this view to another user called amazon_business_analyst and then query from that user.

  1. Sign in to the Lake Formation console as admin.
  2. In the navigation pane, choose Views.

As shown in the following screenshot, you can see the hidden_customerid view.

  1. Sign in as the amazon_business_analyst user and navigate to the Views page.

This user has no visibility to the view.

  1. Grant permission to the amazon_business_analyst user from the data lake admin.
  1. Sign in again as amazon_business_analyst and navigate to the Views page.

  1. On the Athena console, query the hidden_customerid view.

You have successfully shared a view to the user and queried it from the Athena console.

Clean up

To avoid incurring future charges, delete the CloudFormation stack. For instructions, refer to Deleting a stack on the AWS CloudFormation console.

Conclusion

In this post, we demonstrated how to use the AWS Glue Data Catalog to create views. We then showed how to alter the views and mask the data. You can share the view with different users to query using Athena. For more information about this new feature, refer to Using AWS Glue Data Catalog views.


About the Authors

Leonardo Gomez is a Principal Analytics Specialist Solutions Architect at AWS. He has over a decade of experience in data management, helping customers around the globe address their business and technical needs. Connect with him on LinkedIn

Michael Chess – is a Product Manager on the AWS Lake Formation team based out of Palo Alto, CA. He specializes in permissions and data catalog features in the data lake.

Derek Liu – is a Senior Solutions Architect based out of Vancouver, BC. He enjoys helping customers solve big data challenges through AWS analytic services.

The collective thoughts of the interwebz