Final days for some Arm platforms

Post Syndicated from original https://lwn.net/Articles/842574/rss

Arnd Bergmann stirred up a bit of a discussion with his January 8 “bring
out your dead” posting
, wherein he raised the idea of removing support
for a long list of seemingly unloved Arm platforms — and a few non-Arm ones
as well. Many of these have seen no significant work in at least six
years. In a
January 13 followup
, he notes that several of those platforms will
be spared for now due to ongoing interest. Several others, though (efm32,
picoxcell, prima2, tango, u300, and zx) remain on the chopping block, and
the status of another handful remains uncertain. Readers who care about
old Arm platforms may want to have a look at the list now and speak up if
they still need support for one of the platforms that might otherwise be
deleted.

Automating Recommendation Engine Training with Amazon Personalize and AWS Glue

Post Syndicated from Alexander Spivak original https://aws.amazon.com/blogs/architecture/automating-recommendation-engine-training-with-amazon-personalize-and-aws-glue/

Customers from startups to enterprises observe increased revenue when personalizing customer interactions. Still, many companies are not yet leveraging the power of personalization, or, are relying solely on rule-based strategies. Those strategies are effort-intensive to maintain and not effective. Common reasons for not launching machine learning (ML) based personalization projects include: the complexity of aggregating and preparing the datasets, gaps in data science expertise and the lack of trust regarding the quality of ML recommendations.

This blog post demonstrates an approach for product recommendations to mitigate those concerns using historical datasets. To get started with your personalization journey, you don’t need ML expertise or a data lake. The following serverless end-to-end architecture involves aggregating and transforming the required data, as well as automatically training an ML-based recommendation engine.

I will outline the architectural production-ready setup for personalized product recommendations based on historical datasets. This is of interest to data analysts who look for ways to bring an existing recommendation engine to production, as well as solutions architects new to ML.

Solution Overview

The two core elements to create a proof-of-concept for ML-based product recommendations are:

  1. the recommendation engine and,
  2. the data set to train the recommendation engine.

Let’s start with the recommendation engine first, and work backwards to the corresponding data needs.

Product recommendation engine

To create the product recommendation engine, we use Amazon Personalize. Amazon Personalize differentiates three types of input data:

  1. user events called interactions (user events like views, signups or likes),
  2. item metadata (description of your items: category, genre or availability), and
  3. user metadata (age, gender, or loyalty membership).

An interactions dataset is typically the minimal requirement to build a recommendation system. Providing user and item metadata datasets improves recommendation accuracy, and enables cold starts, item discovery and dynamic recommendation filtering.

Most companies already have existing historical datasets to populate all three input types. In the case of retail companies, the product order history is a good fit for interactions. In the case of the media and entertainment industry, the customer’s consumption history maps to the interaction dataset. The product and media catalogs map to the items dataset and the customer profiles to the user dataset.

Amazon Personalize: from datasets to a recommendation API

Amazon Personalize: from datasets to a recommendation API

The Amazon Personalize Deep Dive Series provides a great introduction into the service and explores the topics of training, inference and operations. There are also multiple blog posts available explaining how to create a recommendation engine with Amazon Personalize and how to select the right metadata for the engine training. Additionally, the Amazon Personalize samples repository in GitHub showcases a variety of topics: from getting started with Amazon Personalize, up to performing a POC in a Box using existing datasets, and, finally, automating the recommendation engine with MLOps. In this post, we focus on getting the data from the historical data sources into the structure required by Amazon Personalize.

Creating the dataset

While manual data exports are a quick way to get started with one-time datasets for experiments, we use AWS Glue to automate this process. The automated approach with AWS Glue speeds up the proof of concept (POC) phase and simplifies the process to production by:

  • easily reproducing dataset exports from various data sources. This are used to iterate with other feature sets for recommendation engine training.
  • adding additional data sources and using those to enrich existing datasets
  • efficiently performing transformation logic like column renaming and fuzzy matching out of the box with code generation support.

AWS Glue is a serverless data integration service that is scalable and simple to use. It provides all of the capabilities needed for data integration and supports a wide variety of data sources: Amazon S3 buckets, JDBC connectors, MongoDB databases, Kafka, and Amazon Redshift, the AWS data warehouse. You can even make use of data sources living outside of your AWS environment, e.g. on-premises data centers or other services outside of your VPC. This enables you to perform a data-driven POC even when the data is not yet in AWS.

Modern application environments usually combine multiple heterogeneous database systems, like operational relational and NoSQL databases, in addition to, the BI-powering data warehouses. With AWS Glue, we orchestrate the ETL (extract, transform, and load) jobs to fetch the relevant data from the corresponding data sources. We then bring it into a format that Amazon Personalize understands: CSV files with pre-defined column names hosted in an Amazon S3 bucket.

Each dataset consists of one or multiple CSV files, which can be uniquely identified by an Amazon S3 prefix. Additionally, each dataset must have an associated schema describing the structure of your data. Depending on the dataset type, there are required and pre-defined fields:

  • USER_ID (string) and one additional metadata field for the users dataset
  • ITEM_ID (string) and one additional metadata field for the items dataset
  • USER_ID (string), ITEM_ID (string), TIMESTAMP (long; as Epoch time) for the interactions dataset

The following graph presents a high-level architecture for a retail customer, who has a heterogeneous data store landscape.

Using AWS Glue to export datasets from heterogeneous data sources to Amazon S3

Using AWS Glue to export datasets from heterogeneous data sources to Amazon S3

To understand how AWS Glue connects to the variety of data sources and allows transforming the data into the required format, we need to drill down into the AWS Glue concepts and components.

One of the key components of AWS Glue is the AWS Glue Data Catalog: a persistent metadata store containing table definitions, connection information, as well as, the ETL job definitions.
The tables are metadata definitions representing the structure of the data in the defined data sources. They do not contain any data entries from the sources but solely the structure definition. You can create a table either manually or automatically by using AWS Glue Crawlers.

AWS Glue Crawlers scan the data in the data sources, extract the schema information from it, and store the metadata as tables in the AWS Glue Data Catalog. This is the preferred approach for defining tables. The crawlers use AWS Glue Connections to connect to the data sources. Each connection contains the properties that are required to connect to a particular data store. The connections will be also used later by the ETL jobs to fetch the data from the data sources.

AWS Glue Crawlers also help to overcome a challenge frequently appearing in microservice environments. Microservice architectures are frequently operated by fully independent and autonomous teams. This means that keeping track of changes to the data source format becomes a challenge. Based on a schedule, the crawlers can be triggered to update the metadata for the relevant data sources in the AWS Glue Data Catalog automatically. To detect cases when a schema change would break the ETL job logic, you can combine the CloudWatch Events emitted by AWS Glue on updating the Data Catalog tables with an AWS Lambda function or a notification send via the Amazon Simple Notification Service (SNS).

The AWS Glue ETL jobs use the defined connections and the table information from the Data Catalog to extract the data from the described sources, apply the user-defined transformation logic and write the results into a data sink. AWS Glue can automatically generate code for ETL jobs to help perform a variety of useful data transformation tasks. AWS Glue Studio makes the ETL development even simpler by providing an easy-to-use graphical interface that accelerates the development and allows designing jobs without writing any code. If required, the generated code can be fully customized.

AWS Glue supports Apache Spark jobs, written either in Python or in Scala, and Python Shell jobs. Apache Spark jobs are optimized to run in a highly scalable, distributed way dealing with any amount of data and are a perfect fit for data transformation jobs. The Python Shell jobs provide access to the raw Python execution environment, which is less scalable but provides a cost-optimized option for orchestrating AWS SDK calls.

The following diagram visualizes the interaction between the components described.

The basic concepts of populating your Data Catalog and processing ETL dataflow in AWS Glue

The basic concepts of populating your Data Catalog and processing ETL dataflow in AWS Glue

For each Amazon Personalize dataset type, we create a separate ETL job. Since those jobs are independent, they also can run in parallel. After all jobs have successfully finished, we can start the recommendation engine training. AWS Glue Workflows allow simplifying data pipelines by visualizing and monitoring complex ETL activities involving multiple crawlers, jobs, and triggers, as a single entity.

The following graph visualizes a typical dataset export workflow for training a recommendation engine, which consists of:

  • a workflow trigger being either manual or scheduled
  • a Python Shell job to remove the results of the previous export workflow from S3
  • a trigger firing when the removal job is finished and initiating the parallel execution of the dataset ETL jobs
  • the three Apache Spark ETL jobs, one per dataset type
  • a trigger firing when all three ETL jobs are finished and initiating the training notification job
  • a Python Shell job to initiate a new dataset import or a full training cycle in Amazon Personalize (e.g. by triggering the MLOps pipeline using the AWS SDK)

 

AWS Glue workflow for extracting the three datasets and triggering the training workflow of the recommendation engine

AWS Glue workflow for extracting the three datasets and triggering the training workflow of the recommendation engine

Combining the data export and the recommendation engine

In the previous sections, we discussed how to create an ML-based recommendation engine and how to create the datasets for the training of the engine. In this section, we combine both parts of the solution leveraging an adjusted version of the MLOps pipeline solution available on GitHub to speed up the iterations on new solution versions by avoiding manual steps. Moreover, automation means new items can be put faster into production.

The MLOps pipeline uses a JSON file hosted in an S3 bucket to describe the training parameters for Amazon Personalize. The creation of a new parameter file version triggers a new training workflow orchestrated in a serverless manner using AWS Step Functions and AWS Lambda.

To integrate the Glue data export workflow described in the previous section, we also enable the Glue workflow to trigger the training pipeline. Additionally, we manipulate the pipeline to read the parameter file as the first pipeline step. The resulting architecture enables an automated end-to-end set up from dataset export up to the recommendation engine creation.

End-to-end architecture combining the data export with AWS Glue, the MLOps training workflow and Amazon Personalize

End-to-end architecture combining the data export with AWS Glue, the MLOps training workflow, and Amazon Personalize

The architecture for the end-to-end data export and recommendation engine creation solution is completely serverless. This makes it highly scalable, reliable, easy to maintain, and cost-efficient. You pay only for what you consume. For example, in the case of the data export, you pay only for the duration of the AWS Glue crawler executions and ETL jobs. These are only need to run to iterate with a new dataset.

The solution is also flexible in terms of the connected data sources. This architecture is also recommended for use cases with a single data source. You can also start with a single data store and enrich the datasets on-demand with additional data sources in future iterations.

Testing the quality of the solution

A common approach to validate the quality of the solution is the A/B testing technique, which is widely used to measure the efficacy of generated recommendations. Based on the testing results, you can iterate on the recommendation engine by optimizing the underlying datasets and models. The high degree of automation increases the speed of iterations and the resiliency of the end-to-end process.

Conclusion

In this post, I presented a typical serverless architecture for a fully automated, end-to-end ML-based recommendation engine leveraging available historical datasets. As you begin to experiment with ML-based personalization, you will unlock value currently hidden in the data. This helps mitigate potential concerns like the lack of trust in machine learning and you can put the resulting engine into production.

Start your personalization journey today with the Amazon Personalize code samples and bring the engine to production with the architecture outlined in this blog. As a next step, you can involve recording real-time events to update the generated recommendations automatically based on the event data.

 

Не, няма да има различни лични карти за „родените в чужбина“

Post Syndicated from original https://yurukov.net/blog/2021/lichni-karti/

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

Всъщност, няма нищо общо с „българите родени в чужбина“ и съобщението води до сериозно объркване. Българите родени в чужбина са такива с поне един родител българин. За последните 30 години знаем за малко над 300 хиляди такива. Това са само онези, на които родителите са извадили българско гражданство или сами са възстановили такова на по-късен етап. Те си вадят лесно паспорти като деца заедно с пълноправно гражданство. Вече доколко е трудно да се вадят актовете за раждане съм писал вече тук, тук и тук.

Това, което се говори в аргументите на ВМРО, са хора без българско гражданство, които в последните десетилетия не са намерили пари да им платят за такова, че да стане „по бързия начин“. Новият документ наистина ще важи само за България и има силата на постоянно пребиваване. Създава обаче поредна възможност за корупция за ВМРО, тъй като заобикаля много механизми на проверка. Именно заради последните беше разкрита схемата им за милиони за продажба на гражданство на руски олигарси и албански наркотрафиканти.

И докато аргументите, че щяла да помага на демографията, звучат добре на хартия, няма причини да се смята, че ще е нещо повече от поредната им касичка. Да не говорим, че никой до сега не е успял да покаже от къде идват тези им сметки за 5 млн. етнически българи зад граница. Питах многократно, включително Харалампиев преди да го арестуват за същите неща, които обсъждаме тук. Отказаха ми от контролираната от ВМРО Агенция за българите в чужбина, защото „не им било работа“. Подобни хвъркати твърдения за броя на българите в чужбина чуваме най-редовно – например от КНСБ и от Агенцията за инвестиции.

Така за пореден път използват измислени числа и сензации за демографията, за да създават нови схеми, вместо да оправят една нарочно счупена система за натурализация. Така ДАБЧ става първа и последна инстанция за (про)даване на постоянно пребиваване, прескачайки всички институции, включително ДАНС.

Законопроекта може да прочете тук заедно с всички становища по него. Забавното е, че на няколко пъти, са им казали, че противоречи на европейското законодателство, както и на други закони като този за получаване на постоянно пребиваване. Това не пречи да са го гласували днес на първо четене. Изглежда просто като пиратка за предизборна кампания лишена от смисъл. Дори да се приеме, няма да е повече от корупционна схема докато не ни съдят от ЕК и платим ние глобата от данъците си.

The post Не, няма да има различни лични карти за „родените в чужбина“ first appeared on Блогът на Юруков.

Security updates for Wednesday

Post Syndicated from original https://lwn.net/Articles/842557/rss

Security updates have been issued by Debian (coturn, imagemagick, and spice-vdagent), Fedora (roundcubemail and sympa), Gentoo (asterisk and virtualbox), Oracle (kernel and kernel-container), Red Hat (dotnet3.1, dotnet5.0, and thunderbird), SUSE (crmsh, firefox, hawk2, ImageMagick, kernel, libzypp, zypper, nodejs10, nodejs14, openstack-dashboard, release-notes-suse-openstack-cloud, and tcmu-runner), and Ubuntu (coturn).

Мениджъри на пароли

Post Syndicated from Yovko Lambrev original https://yovko.net/password-managers/

Мениджъри на пароли

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

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

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

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

Неотдавна Wired метафорично нарече тези инструменти зеленчуците на Интернет, защото е всеизвестно, че са полезни за здравето, но мнозина още залитат по нездравословното.

Password manager-ът е софтуер, който съхранява пароли за различни сайтове и системи. Разбира се, криптирано. А достъпът до тях се отключва с някаква главна (master) парола, която трябва да се помни много добре, защото е ключ към останалите. С две думи казано, password manager-ът е нещо като сейф за пароли.

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

  • генератори на различни по дължина и сложност пароли;
  • анализатори и индикатори на трудността на отгатване на паролите;
  • лесно въвеждане на паролите чрез различни плъгини за браузъри;
  • двуфакторна оторизация чрез TOTP (базирани на времето еднократни пароли), макар че по-добре да се ползва друго приложение за тази цел;
  • уведомления дали някоя от паролите ви не е била компрометирана след атака спрямо даден сайт (т.е. дали някъде вече не я продават);
  • споделяне на някои пароли със семейството или колегите;
  • напомняне за пароли, които не сте сменяли отдавна; и др.

Разбира се, че някои неща изглеждат и като нож с две остриета. Има рискове и евентуални проблеми. Например, ако забравите master паролата си, ще загубите и всичките си пароли в мениджъра и ще трябва сайт по сайт да възстановявате достъпа си. А този процес ще отнеме дни и седмици.

Чудите се, можете ли да доверите всичките си пароли на някакъв софтуер… и дали уязвимост в него не ви компрометира изцяло? И това са съвсем резонни тревоги. Но повечето популярни мениджъри на пароли се стараят да ползват сигурни криптографски алгоритми, кодът им се проверява и одитира, и в общия случай удобството и възможността да имате различна парола за всеки сайт или система е труднопостижимо по друг начин. В добавка, рискът да бъде компрометиран мениджърът ви за пароли със сигурност е далеч по-малък от това да ползвате сходни или еднакви пароли на много места.

Можете да подсигурите допълнително master паролата си с многофакторна оторизация, но за това някой друг път.

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

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

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

Иначе многообразието от мениджъри на пароли е голямо. Важно е да изберете това приложение, което ви предлага максимално удобство и онези функции, които са важни за вас. Както и да поддържа и операционните системи, които ползвате. Има безплатни и платени версии, както и такива с отворен код или не. Има и такива с базови безплатни версии, но се плаща за някои от екстрите.

Някои от най-популярните са 1Password, LastPass, DashLine, Bitwarden, KeePassXC, NordPass. Аз години наред ползвах 1Password за лични, семейни и служебни цели, но напоследък ползвам, предпочитам и препоръчвам Bitwarden, който има и безплатна версия и е с отворен код.

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

И преди да ви оставя да си търсите и избирате password manager, да подшушна нещо като евентуална предпазна мярка срещу едно подхлъзване. Много от тези инструменти ще ви предложат да се грижат и за двуфакторната ви оторизация чрез базирани на времето еднократни кодове (на англ. TOTP). Ако не знаете какво е това, изчакайте малко – скоро ще пиша и по тази тема. Сега само бързам да кажа, че много добре знам колко удобно е да се подлъжете да ползвате мениджъра си за пароли и за това, особено като усетите колко лесно се ползва при логване насам-натам, но… уви, това не е добра идея. Целта на втория фактор е именно да е… втори. Не слагайте всички яйца в една кошница. Препоръчително е да оставите тази работа на друго, отделно приложение.

Заглавна снимка: Franck

Мениджъри на пароли

Post Syndicated from Йовко Ламбрев original https://yovko.net/password-managers/

Мениджъри на пароли

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

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

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

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

Неотдавна Wired метафорично нарече тези инструменти зеленчуците на Интернет, защото е всеизвестно, че са полезни за здравето, но мнозина още залитат по нездравословното.

Password manager-ът е софтуер, който съхранява пароли за различни сайтове и системи. Разбира се, криптирано. А достъпът до тях се отключва с някаква главна (master) парола, която трябва да се помни много добре, защото е ключ към останалите. С две думи казано, password manager-ът е нещо като сейф за пароли.

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

  • генератори на различни по дължина и сложност пароли;
  • анализатори и индикатори на трудността на отгатване на паролите;
  • лесно въвеждане на паролите чрез различни плъгини за браузъри;
  • двуфакторна оторизация чрез TOTP (базирани на времето еднократни пароли), макар че по-добре да се ползва друго приложение за тази цел;
  • уведомления дали някоя от паролите ви не е била компрометирана след атака спрямо даден сайт (т.е. дали някъде вече не я продават);
  • споделяне на някои пароли със семейството или колегите;
  • напомняне за пароли, които не сте сменяли отдавна; и др.

Разбира се, че някои неща изглеждат и като нож с две остриета. Има рискове и евентуални проблеми. Например, ако забравите master паролата си, ще загубите и всичките си пароли в мениджъра и ще трябва сайт по сайт да възстановявате достъпа си. А този процес ще отнеме дни и седмици.

Чудите се, можете ли да доверите всичките си пароли на някакъв софтуер… и дали уязвимост в него не ви компрометира изцяло? И това са съвсем резонни тревоги. Но повечето популярни мениджъри на пароли се стараят да ползват сигурни криптографски алгоритми, кодът им се проверява и одитира, и в общия случай удобството и възможността да имате различна парола за всеки сайт или система е труднопостижимо по друг начин. В добавка, рискът да бъде компрометиран мениджърът ви за пароли със сигурност е далеч по-малък от това да ползвате сходни или еднакви пароли на много места.

Можете да подсигурите допълнително master паролата си с многофакторна оторизация, но за това някой друг път.

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

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

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

Иначе многообразието от мениджъри на пароли е голямо. Важно е да изберете това приложение, което ви предлага максимално удобство и онези функции, които са важни за вас. Както и да поддържа и операционните системи, които ползвате. Има безплатни и платени версии, както и такива с отворен код или не. Има и такива с базови безплатни версии, но се плаща за някои от екстрите.

Някои от най-популярните са 1Password, LastPass, DashLine, Bitwarden, KeePassXC, NordPass. Аз години наред ползвах 1Password за лични, семейни и служебни цели, но напоследък ползвам, предпочитам и препоръчвам Bitwarden, който има и безплатна версия и е с отворен код.

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

И преди да ви оставя да си търсите и избирате password manager, да подшушна нещо като евентуална предпазна мярка срещу едно подхлъзване. Много от тези инструменти ще ви предложат да се грижат и за двуфакторната ви оторизация чрез базирани на времето еднократни кодове (на англ. TOTP). Ако не знаете какво е това, изчакайте малко – скоро ще пиша и по тази тема. Сега само бързам да кажа, че много добре знам колко удобно е да се подлъжете да ползвате мениджъра си за пароли и за това, особено като усетите колко лесно се ползва при логване насам-натам, но… уви, това не е добра идея. Целта на втория фактор е именно да е… втори. Не слагайте всички яйца в една кошница. Препоръчително е да оставите тази работа на друго, отделно приложение.

Заглавна снимка: Franck

Мениджъри на пароли

Post Syndicated from Йовко Ламбрев original https://yovko.net/password-managers/

Мениджъри на пароли

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

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

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

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

Неотдавна Wired метафорично нарече тези инструменти зеленчуците на Интернет, защото е всеизвестно, че са полезни за здравето, но мнозина още залитат по нездравословното.

Password manager-ът е софтуер, който съхранява пароли за различни сайтове и системи. Разбира се, криптирано. А достъпът до тях се отключва с някаква главна (master) парола, която трябва да се помни много добре, защото е ключ към останалите. С две думи казано, password manager-ът е нещо като сейф за пароли.

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

  • генератори на различни по дължина и сложност пароли;
  • анализатори и индикатори на трудността на отгатване на паролите;
  • лесно въвеждане на паролите чрез различни плъгини за браузъри;
  • двуфакторна оторизация чрез TOTP (базирани на времето еднократни пароли), макар че по-добре да се ползва друго приложение за тази цел;
  • уведомления дали някоя от паролите ви не е била компрометирана след атака спрямо даден сайт (т.е. дали някъде вече не я продават);
  • споделяне на някои пароли със семейството или колегите;
  • напомняне за пароли, които не сте сменяли отдавна; и др.

Разбира се, че някои неща изглеждат и като нож с две остриета. Има рискове и евентуални проблеми. Например, ако забравите master паролата си, ще загубите и всичките си пароли в мениджъра и ще трябва сайт по сайт да възстановявате достъпа си. А този процес ще отнеме дни и седмици.

Чудите се, можете ли да доверите всичките си пароли на някакъв софтуер… и дали уязвимост в него не ви компрометира изцяло? И това са съвсем резонни тревоги. Но повечето популярни мениджъри на пароли се стараят да ползват сигурни криптографски алгоритми, кодът им се проверява и одитира, и в общия случай удобството и възможността да имате различна парола за всеки сайт или система е труднопостижимо по друг начин. В добавка, рискът да бъде компрометиран мениджърът ви за пароли със сигурност е далеч по-малък от това да ползвате сходни или еднакви пароли на много места.

Можете да подсигурите допълнително master паролата си с многофакторна оторизация, но за това някой друг път.

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

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

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

Иначе многообразието от мениджъри на пароли е голямо. Важно е да изберете това приложение, което ви предлага максимално удобство и онези функции, които са важни за вас. Както и да поддържа и операционните системи, които ползвате. Има безплатни и платени версии, както и такива с отворен код или не. Има и такива с базови безплатни версии, но се плаща за някои от екстрите.

Някои от най-популярните са 1Password, LastPass, DashLine, Bitwarden, KeePassXC, NordPass. Аз години наред ползвах 1Password за лични, семейни и служебни цели, но напоследък ползвам, предпочитам и препоръчвам Bitwarden, който има и безплатна версия и е с отворен код.

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

И преди да ви оставя да си търсите и избирате password manager, да подшушна нещо като евентуална предпазна мярка срещу едно подхлъзване. Много от тези инструменти ще ви предложат да се грижат и за двуфакторната ви оторизация чрез базирани на времето еднократни кодове (на англ. TOTP). Ако не знаете какво е това, изчакайте малко – скоро ще пиша и по тази тема. Сега само бързам да кажа, че много добре знам колко удобно е да се подлъжете да ползвате мениджъра си за пароли и за това, особено като усетите колко лесно се ползва при логване насам-натам, но… уви, това не е добра идея. Целта на втория фактор е именно да е… втори. Не слагайте всички яйца в една кошница. Препоръчително е да оставите тази работа на друго, отделно приложение.

Заглавна снимка: Franck

Мениджъри на пароли

Post Syndicated from Йовко Ламбрев original https://yovko.net/password-managers/

Мениджъри на пароли

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

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

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

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

Неотдавна Wired метафорично нарече тези инструменти зеленчуците на Интернет, защото е всеизвестно, че са полезни за здравето, но мнозина още залитат по нездравословното.

Password manager-ът е софтуер, който съхранява пароли за различни сайтове и системи. Разбира се, криптирано. А достъпът до тях се отключва с някаква главна (master) парола, която трябва да се помни много добре, защото е ключ към останалите. С две думи казано, password manager-ът е нещо като сейф за пароли.

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

  • генератори на различни по дължина и сложност пароли;
  • анализатори и индикатори на трудността на отгатване на паролите;
  • лесно въвеждане на паролите чрез различни плъгини за браузъри;
  • двуфакторна оторизация чрез TOTP (базирани на времето еднократни пароли), макар че по-добре да се ползва друго приложение за тази цел;
  • уведомления дали някоя от паролите ви не е била компрометирана след атака спрямо даден сайт (т.е. дали някъде вече не я продават);
  • споделяне на някои пароли със семейството или колегите;
  • напомняне за пароли, които не сте сменяли отдавна; и др.

Разбира се, че някои неща изглеждат и като нож с две остриета. Има рискове и евентуални проблеми. Например, ако забравите master паролата си, ще загубите и всичките си пароли в мениджъра и ще трябва сайт по сайт да възстановявате достъпа си. А този процес ще отнеме дни и седмици.

Чудите се, можете ли да доверите всичките си пароли на някакъв софтуер… и дали уязвимост в него не ви компрометира изцяло? И това са съвсем резонни тревоги. Но повечето популярни мениджъри на пароли се стараят да ползват сигурни криптографски алгоритми, кодът им се проверява и одитира, и в общия случай удобството и възможността да имате различна парола за всеки сайт или система е труднопостижимо по друг начин. В добавка, рискът да бъде компрометиран мениджърът ви за пароли със сигурност е далеч по-малък от това да ползвате сходни или еднакви пароли на много места.

Можете да подсигурите допълнително master паролата си с многофакторна оторизация, но за това някой друг път.

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

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

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

Иначе многообразието от мениджъри на пароли е голямо. Важно е да изберете това приложение, което ви предлага максимално удобство и онези функции, които са важни за вас. Както и да поддържа и операционните системи, които ползвате. Има безплатни и платени версии, както и такива с отворен код или не. Има и такива с базови безплатни версии, но се плаща за някои от екстрите.

Някои от най-популярните са 1Password, LastPass, DashLine, Bitwarden, KeePassXC, NordPass. Аз години наред ползвах 1Password за лични, семейни и служебни цели, но напоследък ползвам, предпочитам и препоръчвам Bitwarden, който има и безплатна версия и е с отворен код.

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

И преди да ви оставя да си търсите и избирате password manager, да подшушна нещо като евентуална предпазна мярка срещу едно подхлъзване. Много от тези инструменти ще ви предложат да се грижат и за двуфакторната ви оторизация чрез базирани на времето еднократни кодове (на англ. TOTP). Ако не знаете какво е това, изчакайте малко – скоро ще пиша и по тази тема. Сега само бързам да кажа, че много добре знам колко удобно е да се подлъжете да ползвате мениджъра си за пароли и за това, особено като усетите колко лесно се ползва при логване насам-натам, но… уви, това не е добра идея. Целта на втория фактор е именно да е… втори. Не слагайте всички яйца в една кошница. Препоръчително е да оставите тази работа на друго, отделно приложение.

Заглавна снимка: Franck

Мениджъри на пароли

Post Syndicated from Yovko Lambrev original https://yovko.net/password-managers/

Мениджъри на пароли

Още помня първата си парола, която използвах в Интернет някъде преди около 25 години. Разбира се, че по онова време бях немарлив и съм я ползвал на повече от едно място, и не съм я сменял дълго време. А много от сайтовете тогава не можеха да се похвалят със сигурността си. За съжаление и до днес има такива. А когато кракери пробият сигурността на някой уебсайт, се случва и да откраднат паролите на всички регистрирани в него. Принципно сайтовете не трябва да пазят пароли, но нямате идея колко го правят. Има и продажни администратори, които нарочно събират пароли на потребителите си, за да могат да пробват дали същия потребител, чийто имейл им е известен не използва същата парола и потребителско име и някъде другаде в Интернет. Такива пакети с откраднати пароли се продават (и купуват) в тъмната мрежа безгрижно.

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

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

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

Неотдавна Wired метафорично нарече тези инструменти зеленчуците на Интернет, защото е всеизвестно, че са полезни за здравето, но мнозина още залитат по нездравословното.

Password manager-а е софтуер, който съхранява пароли за различни сайтове и системи. Разбира се, криптирано. Като достъпът до тях се отключва с някаква главна (master) парола, която трябва да се помни много добре, защото е ключ към останалите. С две думи казано password manager е нещо като сейф за пароли.

В добавка различните такива могат да предлагат цяла купчина допълнителни екстри. Например:

  • генератори на различни по дължина и сложност пароли
  • анализатори и индикатори на трудността на отгатване на паролите
  • лесно въвеждане на паролите чрез различни плъгини за браузъри
  • двуфакторна оторизация чрез TOTP (базирани на времето еднократни пароли), макар че по-добре да се ползва друго приложение за тази цел
  • уведомления дали някоя от паролите ви не е била компрометирана след атака спрямо даден сайт (т.е. дали някъде вече не продават паролата ви)
  • споделяне на някои пароли със семейството или колегите
  • напомняния за пароли, които не сте сменяли отдавна и др.

Разбира се, че някои неща изглеждат и като нож с две остриета. Има рискове и евентуални проблеми. Например, ако забравите master паролата си, ще останете без достъп до всичките ви пароли в мениджъра и ще трябва сайт по сайт да възстановявате достъпа си. А този процес ще отнеме дни и седмици. Чудите се, можете ли да доверите всичките си пароли на някакъв софтуер… и дали уязвимост в него не ви компрометира изцяло. И това са съвсем резонни тревоги.

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

Можете да подсигурите допълнително master паролата си с многофакторна оторизация, но за това някой друг път.

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

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

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

Иначе многообразието от мениджъри на пароли е голямо. Важно да е изберете това приложение, което ви предлага максимално удобство и тези функции, които са важни за вас. Както и да поддържа и операционните системи, които ползвате. Има безплатни и платени версии, както и такива с отворен код или не. Има и такива, които имат базови безплатни версии, но се плаща за някои от екстрите.

Някои от най-популярните са 1Password, LastPass, DashLine, Bitwarden, KeePassXC, NordPass. Аз години наред ползвах 1Password за лични, семейни и служебни цели, но напоследък ползвам, предпочитам и препоръчвам Bitwarden, който има и безплатна версия и е с отворен код.

И преди да ви оставя да си търсите и избирате password manager, да подшушна нещо като евентуална предпазна мярка срещу едно подхлъзване. Много от тези инструменти ще ви предложат да се грижат и за двуфакторната ви оторизация, чрез базирани на времето еднократни кодове (на англ. TOTP). Ако не знаете какво е това, изчакайте малко – скоро ще пиша и по тази тема. Сега само бързам да кажа, че много добре знам колко адски удобно е да се подлъжете да ползвате мениджъра си за пароли и за това, особено като опитате колко лесно се ползва при логване насам-натам, но… уви, това не е добра идея. Идеята на втория фактор е именно да е… втори. Не слагайте всички яйца в една кошница. Препоръчително е да оставите тази работа на друго, отделно приложение.

Заглавна снимка: Franck

On US Capitol Security — By Someone Who Manages Arena-Rock-Concert Security

Post Syndicated from Bruce Schneier original https://www.schneier.com/blog/archives/2021/01/on-us-capitol-security-by-someone-who-manages-arena-rock-concert-security.html

Smart commentary:

…I was floored on Wednesday when, glued to my television, I saw police in some areas of the U.S. Capitol using little more than those same mobile gates I had ­ the ones that look like bike racks that can hook together ­ to try to keep the crowds away from sensitive areas and, later, push back people intent on accessing the grounds. (A new fence that appears to be made of sturdier material was being erected on Thursday.) That’s the same equipment and approximately the same amount of force I was able to use when a group of fans got a little feisty and tried to get backstage at a Vanilla Ice show.

[…]

There’s not ever going to be enough police or security at any event to stop people if they all act in unison; if enough people want to get to Vanilla Ice at the same time, they’re going to get to Vanilla Ice. Social constructs and basic decency, not lightweight security gates, are what hold everyone except the outliers back in a typical crowd.

[…]

When there are enough outliers in a crowd, it throws the normal dynamics of crowd control off; everyone in my business knows this. Citizens tend to hold each other to certain standards ­ which is why my 40,000-person town does not have 40,000 police officers, and why the 8.3 million people of New York City aren’t policed by 8.3 million police officers.

Social norms are the fabric that make an event run smoothly — and, really, hold society together. There aren’t enough police in your town to handle it if everyone starts acting up at the same time.

I like that she uses the term “outliers,” and I make much the same points in Liars and Outliers.

A Name Resolver for the Distributed Web

Post Syndicated from Thibault Meunier original https://blog.cloudflare.com/cloudflare-distributed-web-resolver/

A Name Resolver for the Distributed Web

A Name Resolver for the Distributed Web

The Domain Name System (DNS) matches names to resources. Instead of typing 104.18.26.46 to access the Cloudflare Blog, you type blog.cloudflare.com and, using DNS, the domain name resolves to 104.18.26.46, the Cloudflare Blog IP address.

Similarly, distributed systems such as Ethereum and IPFS rely on a naming system to be usable. DNS could be used, but its resolvers’ attributes run contrary to properties valued in distributed Web (dWeb) systems. Namely, dWeb resolvers ideally provide (i) locally verifiable data, (ii) built-in history, and (iii) have no single trust anchor.

At Cloudflare Research, we have been exploring alternative ways to resolve queries to responses that align with these attributes. We are proud to announce a new resolver for the Distributed Web, where IPFS content indexed by the Ethereum Name Service (ENS) can be accessed.

To discover how it has been built, and how you can use it today, read on.

Welcome to the Distributed Web

IPFS and its addressing system

The InterPlanetary FileSystem (IPFS) is a peer-to-peer network for storing content on a distributed file system. It is composed of a set of computers called nodes that store and relay content using a common addressing system.

This addressing system relies on the use of Content IDentifiers (CID). CIDs are self-describing identifiers, because the identifier is derived from the content itself. For example, QmXoypizjW3WknFiJnKLwHCnL72vedxjQkDDP1mXWo6uco is the CID version 0 (CIDv0) of the wikipedia-on ipfs homepage.

To understand why a CID is defined as self-describing, we can look at its binary representation. For QmXoypizjW3WknFiJnKLwHCnL72vedxjQkDDP1mXWo6uco, the CID looks like the following:

A Name Resolver for the Distributed Web

The first is the algorithm used to generate the CID (sha2-256 in this case); then comes the length of the encoded content (32 for a sha2-256 hash), and finally the content itself. When referring to the multicodec table, it is possible to understand how the content is encoded.

Name Code (in hexadecimal)
identity 0x00
sha1 0x11
sha2-256 0x12 = 00010010
keccak-256 0x1b

This encoding mechanism is useful, because it creates a unique and upgradable content-addressing system across multiple protocols.

If you want to learn more, have a look at ProtoSchool’s tutorial.

Ethereum and decentralised applications

Ethereum is an account-based blockchain with smart contract capabilities. Being account-based, each account is associated with addresses and these can be modified by operations grouped in blocks and sealed by Ethereum’s consensus algorithm, Proof-of-Work.

There are two categories of accounts: user accounts and contract accounts. User accounts are controlled by a private key, which is used to sign transactions from the account. Contract accounts hold bytecode, which is executed by the network when a transaction is sent to their account. A transaction can include both funds and data, allowing for rich interaction between accounts.

When a transaction is created, it gets verified by each node on the network. For a transaction between two user accounts, the verification consists of checking the origin account signature. When the transaction is between a user and a smart contract, every node runs the smart contract bytecode on the Ethereum Virtual Machine (EVM). Therefore, all nodes perform the same suite of operations and end up in the same state. If one actor is malicious, nodes will not add its contribution. Since nodes have diverse ownership, they have an incentive to not cheat.

How to access IPFS content

As you may have noticed, while a CID describes a piece of content, it doesn’t describe where to find it. In fact, the CID describes the content, but not its location on the network. The location of the file would be retrieved by a query made to an IPFS node.

An IPFS URL (Unified Resource Locator) looks like this: ipfs://QmXoypizjW3WknFiJnKLwHCnL72vedxjQkDDP1mXWo6uco. Accessing this URL means retrieving QmXoypizjW3WknFiJnKLwHCnL72vedxjQkDDP1mXWo6uco using the IPFS protocol, denoted by ipfs://. However, typing such a URL is quite error-prone. Also, these URLs are not very human-friendly, because there is no good way to remember such long strings. To get around this issue, you can use DNSLink. DNSLink is a way of specifying IPFS CIDs within a DNS TXT record. For instance, wikipedia on ipfs has the following TXT record

$ dig +short TXT _dnslink.en.wikipedia-on-ipfs.org

_dnslink=/ipfs/QmXoypizjW3WknFiJnKLwHCnL72vedxjQkDDP1mXWo6uco

In addition, its A record points to an IPFS gateway. This means that, when you access en.wikipedia-on-ipfs.org, your request is directed to an IPFS HTTP Gateway, which then looks out for the CID using your domain TXT record, and returns the content associated to this CID using the IPFS network.

This is trading ease-of-access against security. The web browser of the user doesn’t verify the integrity of the content served. This could be because the browser does not implement IPFS or because it has no way of validating domain signature — DNSSEC. We wrote about this issue in our previous blog post on End-to-End Integrity.

Human readable identifiers

DNS simplifies referring to IP addresses, in the same way that postal addresses are a way of referring to geolocation data, and contacts in your mobile phone abstract phone numbers. All these systems provide a human-readable format and reduce the error rate of an operation.

To verify these data, the trusted anchors, or “sources of truth”, are:

  • Root DNS Keys for DNS.
  • The government registry for postal addresses. In the UK, addresses are handled by cities, boroughs and local councils.
  • When it comes to your contacts, you are the trust anchor.

Ethereum Name Service, an index for the Distributed Web

An account is identified by its address. An address starts with “0x” and is followed by 20 bytes (ref 4.1 Ethereum yellow paper), for example: 0xf10326c1c6884b094e03d616cc8c7b920e3f73e0. This is not very readable, and can be pretty scary when transactions are not reversible and one can easily mistype a single  character.

A first mitigation strategy was to introduce a new notation to capitalise some letters based on the hash of the address 0xF10326C1c6884b094E03d616Cc8c7b920E3F73E0. This can help detect mistype, but it is still not readable. If I have to send a transaction to a friend, I have no way of confirming she hasn’t mistyped the address.

The Ethereum Name Service (ENS) was created to tackle this issue. It is a system capable of turning human-readable names, referred to as domains, to blockchain addresses. For instance, the domain privacy-pass.eth points to the Ethereum address 0xF10326C1c6884b094E03d616Cc8c7b920E3F73E0.

To achieve this, the system is organised in two components, registries and resolvers.

A registry is a smart contract that maintains a list of domains and some information about each domain: the domain owner and the domain resolver. The owner is the account allowed to manage the domain. They can create subdomains and change ownership of their domain, as well as modify the resolver associated with their domain.

Resolvers are responsible for keeping records. For instance, Public Resolver is a smart contract capable of associating not only a name to blockchain addresses, but also a name to an IPFS content identifier. The resolver address is stored in a registry. Users then contact the registry to retrieve the resolver associated with the name.

Consider a user, Alice, who has direct access to the Ethereum state. The flow goes as follows: Alice would like to get Privacy Pass’s Ethereum address, for which the domain is privacy-pass.eth. She looks for privacy-pass.eth in the ENS Registry and figures out the resolver for privacy-pass.eth is at 0x1234… . She now looks for the address of privacy-pass.eth at the resolver address, which turns out to be 0xf10326c….

A Name Resolver for the Distributed Web

Accessing the IPFS content identifier for privacy-pass.eth works in a similar way. The resolver is the same, only the accessed data is different — Alice calls a different method from the smart contract.

A Name Resolver for the Distributed Web

Cloudflare Distributed Web Resolver

The goal was to be able to use this new way of indexing IPFS content directly from your web browser. However, accessing the ENS registry requires access to the Ethereum state. To get access to IPFS, you would also need to access the IPFS network.

To tackle this, we are going to use Cloudflare’s Distributed Web Gateway. Cloudflare operates both an Ethereum Gateway and an IPFS Gateway, respectively available at cloudflare-eth.com and cloudflare-ipfs.com.

The first version of EthLink was built by Jim McDonald and is operated by True Name LTD at eth.link. Starting from next week, eth.link will transition to use the Cloudflare Distributed Web Resolver. To that end, we have built EthLink on top of Cloudflare Workers. This is a proxy to IPFS. It proxies all ENS registered domains when .link is appended. For instance, privacy-pass.eth should render the Privacy Pass homepage. From your web browser, https://privacy-pass.eth.link does it.

The resolution is done at the Cloudflare edge using a Cloudflare Worker. Cloudflare Workers allows JavaScript code to be run on Cloudflare infrastructure, eliminating the need to maintain a server and increasing the reliability of the service. In addition, it follows Service Workers API, so results returned from the resolver can be checked by end users if needed.

To do this, we setup a wildcard DNS record for *.eth.link to be proxied through Cloudflare and handled by a Cloudflare Worker.  When a user Alice accesses privacy-pass.eth.link, the worker first gets the CID of the CID to be retrieved from Ethereum. Then, it requests the content matching this CID to IPFS, and returns it to Alice.

A Name Resolver for the Distributed Web

All parts can be run locally. The worker can be run in a service Worker, and the Ethereum Gateway can point to both a local Ethereum node and the IPFS gateway provided by IPFS Companion. It means that while Cloudflare provides resolution-as-a-service, none of the components has to be trusted.

Final notes

So are we distributed yet? No, but we are getting closer, building bridges between emerging technologies and current web infrastructure. By providing a gateway dedicated to the distributed web, we hope to make these services more accessible to everyone.

We thank the ENS team for their support of a new resolver on expanding the distributed web. The ENS team has been running a similar service at https://eth.link. On January 18th, they will switch https://eth.link to using our new service.

These services benefit from the added speed and security of the Cloudflare Worker platform, while paving the way to run distributed protocols in browsers.

Supporting teachers and students with remote learning through free video lessons

Post Syndicated from original https://www.raspberrypi.org/blog/supporting-teachers-students-remote-learning-free-video-lessons/

Working with Oak National Academy, we’ve turned the materials from our Teach Computing Curriculum into more than 300 free, curriculum-mapped video lessons for remote learning.

A girl in a hijab learning at home at a laptop

A comprehensive set of free classroom materials

One of our biggest projects for teachers that we’ve worked on over the past two years is the Teach Computing Curriculum: a comprehensive set of free computing classroom materials for key stages 1 to 4 (learners aged 5 to 16). The materials comprise lesson plans, homework, progression mapping, and assessment materials. We’ve created these as part of the National Centre for Computing Education, but they are freely available for educators all over the world to download and use.

More than 300 free, curriculum-mapped video lessons

In the second half of 2020, in response to school closures, our team of experienced teachers produced over 100 hours of video to transform Teach Computing Curriculum materials into video lessons for learning at home. They are freely available for parents, educators, and learners to continue learning computing at home, wherever you are in the world.

Here’s the start of lesson 2 in the Year 8 ‘Computer systems’ unit

You’ll find our videos for more than 300 hour-long lessons on the Oak National Academy website. The progression of the lessons is mapped out clearly, and the videos cover England’s computing national curriculum. There are video lessons for:

  • Years 5 and 6 at key stage 2 (ages 7 to 11)
  • Years 7, 8, and 9 at key stage 3 (ages 11 to 14)
  • Examined (GCSE) as well as non-examined (Digital Literacy) at key stage 4 (ages 14 to 16)

To access the full set of classroom materials for teaching, visit the National Centre for Computing Education website.

The post Supporting teachers and students with remote learning through free video lessons appeared first on Raspberry Pi.

The collective thoughts of the interwebz

By continuing to use the site, you agree to the use of cookies. more information

The cookie settings on this website are set to "allow cookies" to give you the best browsing experience possible. If you continue to use this website without changing your cookie settings or you click "Accept" below then you are consenting to this.

Close