NetWorkWise

networkwise

This is basically the : I wanted and guide I wish I had what why. What With the rise of Google's approach, the concept of "Zero Trust" brought the Identity Aware Proxy to the world. beyond-corp In a nutshell, internal resources or tools sit in private inaccessible areas of the cloud, while a reverse proxy on top of them offers access to permitted users only. The authentication often relies on an OAuth2 provider, but any kind of user directory does the trick. Why Rarely do you enjoy a combination of more than two of these: Security. Quality user experience. Ease of management/maintenance. The magic of “Zero Trust” lies in benefiting from all of the above with the same solution. Security The key feature in an identity-aware proxy is the redundancy of VPN servers. VPN by its nature offers a single point of access to the internal network. Once authenticated, the user has the keys to the kingdom; all internal systems are reachable. In some cases, when is correctly implemented, authentication is still in the way and protects user access. RBAC However, the system is still accessible network-wise, making it susceptible to scans and attacks that might bypass the standard access point. With a reverse proxy, before the request is authorized, all access is blocked as the routing didn't take place. The request was blocked before being rerouted forward. Another aspect of security comes from the fact that the user has one identity source to manage. If has been enabled ( ), it stands for all future user authentication methods. More on that on the ease of access, and, ease of management. MFA / 2FA and it should!!! One clarification before moving on though; this is not to say that VPNs are in the past, or that's something is broken with the concept of having one. Deployed correctly, VPN servers are incredible at what they do. They're ubiquitous for a reason. That said, most implementations lack basic access control, and those that do, more often than not, do not monitor internal queries once a user has been authenticated. In some cases, there are usually not too many alternatives. But for others - e.g. back-office web services, we can do better. Ease of Access This is the more straightforward aspect of things; a user with the organization directory only has to manage one identity. Assuming the user is keeping their passwords safe with something like , and a mandatory , it makes everyone's life easier. 1Password 2 step verification The cookie generated from one successful authentication can be used to access all other systems under the proxy (given the user is permitted to do so). Ease of Management One of the key pain points engineering / IT / Ops teams struggle with is user management when multiple systems and tools are involved in the development. Instead of managing a growing number of directories and user sets, offers a single point of authentication, allowing the management of only one directory. SSO All that's left is to integrate SSO with the identity-aware proxy to leverage both a single access point and the reuse of a cookie. to the rescue! SSO While is simply wonderful in terms of concept and implementation, its docs are somewhat for the lack of a better word. The issue amplifies when trying to deploy on ECS Fargate. (Somewhat surprising given the nature of Buzzfeed's workload on ECS but 🤷). Buzzfeed's SSO incomprehensive The How With that in mind, here's a guide / better-docs for implementing a  "Zero-trust proxy with SSO and cookie reuse on ECS Fargate" ... Probably the world record for the single-line title with most buzzwords ever Buzzfeed's SSO is an implementation of two proxy entities, one service as a proxy to underlying systems and the other as an auth provider. The reason for the local auth provider is being able to serve one login for all systems, instead of having to re-authenticate with every different upstream. This is a cookie-reuse for the same purpose, which is a super elegant solution on behalf of Buzzfeed. Here's a complex, yet comprehensive visual diagram of the system As said, the system comprises of a proxy and an auth provider, namely and (or in short). Both systems are configured by a set of environment variables, where the backend routing is described in an . With growing usage, additional features, switches, parameters, and updates the project kind of grew out of basic understandable configuration docs. This is why we're here today. sso-proxy sso-authenticator sso-auth upstream Yaml config file The Proxy This is the entity that serves as the front gate for incoming requests. If the incoming request is identified as valid, the request goes through and is routed based on . Otherwise, requests are redirected to the authenticator. upstream_configs.yml I've chosen to build the container image with the environment wrapping Buzzfeed's image. This is for convenience only and can be shifted to any other method. Building the image with docker build --build-arg client_id=xxx client_secret=xxx ... FROM buzzfeed/sso

ARG client_id \
    client_secret \
    session_cookie_secret

ENV UPSTREAM_CONFIGFILE="/sso/upstream_configs.yml" \
    UPSTREAM_CLUSTER="" \
    PROVIDER_URL_EXTERNAL="https://sso-auth.domain.co" \
    CLIENT_ID=$client_id \
    CLIENT_SECRET=$client_secret \
    SESSION_COOKIE_SECRET=$session_cookie_secret \
    SESSION_TTL_LIFETIME="1h" \
    UPSTREAM_SCHEME=http

COPY ./upstream_config.yml /sso/upstream_configs.yml

ENTRYPOINT ["/bin/sso-proxy"] The Authenticator Receiving unauthenticated requests from the proxy, the authenticator is in charge of contacting the OAuth2 provider for authorization. According to configuration, if the requesting user has the relevant permissions i.e. authorized domain, correct sub-group, and so on, a cookie is set and redirected to the proxy, which in turn lets it through. Built-in the same manner as its twin, the authenticator is based on the same image, only uses a different and a different set of configuration variables: ENTRYPOINT FROM buzzfeed/sso

ARG client_id \
    client_secret \
    session_cookie_secret \
    session_key

ENV AUTHORIZE_EMAIL_DOMAINS=domain.co \
    AUTHORIZE_PROXY_DOMAINS=domain.co \
    SERVER_HOST=sso-auth.domain.co \
    CLIENT_PROXY_ID=$client_id \
    CLIENT_PROXY_SECRET=$client_secret \
    SESSION_COOKIE_SECURE=true \
    SESSION_COOKIE_SECRET=$session_cookie_secret \
    SESSION_COOKIE_EXPIRE=1h \
    SESSION_KEY=$session_key \
    PROVIDER_X_CLIENT_ID=$client_id \
    PROVIDER_X_CLIENT_SECRET=$client_secret \
    PROVIDER_X_TYPE=google \
    PROVIDER_X_SLUG=google \
    PROVIDER_X_GOOGLE_IMPERSONATE=admin@domain.co \
    PROVIDER_X_GOOGLE_CREDENTIALS=/sso/credentials.json \
    PROVIDER_X_GROUPCACHE_INTERVAL_REFRESH=1m \
    PROVIDER_X_GROUPCACHE_INTERVAL_PROVIDER=1m \
    LOGGING_LEVEL=debug

COPY ./credentials.json /sso/credentials.json

EXPOSE 4180

ENTRYPOINT ["/bin/sso-auth"] OAuth2 Provider of choice - Google Not much to elaborate on Google. Its workspace directory offers a wide range of user management features and is considered a standard choice. Specifically, Buzzfeed's SSO offers either Google or Okta as providers. If these are not the way your organization is managing users this post might be irrelevant for the most part. You can, however, make use of the underlying system - , which will provide a similar experience, except the solution of a single locally managed authentication mechanism. Instead of having two components, the proxy is one system that operates against the backend provider. OAuth2-proxy Instructions (although far from perfect) can be found .
Important notes: here Please do go through all steps, even if some seem unnecessary; like not following step three and forward if group segregation is not a requirement. Do go all the way through it, and make sure you get the .json file at the end. Read carefully, make sure is enabled as shown admin SDK Make sure that from Google's workspace security side, the API controls Make sure the is set with an admin user PROVIDER_X_GOOGLE_IMPERSONATE=admin@domain.co Upstreams Upstreams are a configuration file where proxy routes are set. They take a public request from the web, and, if authenticated is routed to an internal (or not) service given some conditions are met. The configuration below describes two services and their internal routes: - service: vault
  default:
    from: vault.sso.domain.co
    to: vault.local:8200
    options:
      allowed_groups:
        - production@domain.co
- service: snappass
  default:
    from: secrets.sso.domain.co
    to: secrets.local:5000
    options:
      allowed_email_domains:
        - domain.co Notes: Each entry have a setting, other custom settings can follow must default & are the base, while are optional one of the are set. from to options only if top three I've learned this one the hard way... Note how or are set and sufficient on their own. The first is permitting access for a specific directory group, while the latter offers domain-wide access with allowed_groups allowed_email_domains The entire set of can be found options here Deployment The two services above should be deployed together in an internal network just as any other service would. The best practice here dictates a load balancer on top, to route traffic into the proxy/authenticator. The only thing to consider here is the of upstream services; a system that's considered "internal" and will be accessed through the proxy has to be accessible from the proxy itself. On the network level, this means that they either have to sit in the same virtual private network or have a between the networks. From the proxy's perspective, the IP the port should be in reach and open. "Open" also means that they would be part of the same security group, or open a rule in the respective groups to be able to provide back and forth communication. reachability peering and ECS and Service Discovery Once the proxy is set, the user gains access, they should be able to communicate with endpoints only accessible internally within the private network, the . While we can redirect the request to an IP, those tend to change and the connection is then lost. An improvement can be an elastic IP that's guaranteed to stay fixed with the resource it was attached to. This brings a few new issues though; a. the resource itself can (and should) be rotated within time - we are dealing with containers after all. b. Elastic IPs will once their underlying resource no longer exists. Another improvement might be a human-readable DNS A record that's pointed at the same IP. Still, being readable and all, the inherent problem with a static IP remains. VPC start being charged The solution - . Put simply, the service discovery service attaches itself to an ECS target group, updating the live running tasks underneath with an internal endpoint managed by Route53. Meaning, the user can hit the same endpoint and trust it to resolve to a dynamic IP that's connected to an existing task. AWS Service Discovery Here's a quick example using Terraform code (out of convenience only - this can be set manually or using any other language): A global resource of private dns namespace has to be created first before it can host internal records: <img src="{{ site.url }}{{ site.baseurl }}/assets/images/tf-carbon-dns.png"/> After the namespace is ready, we can start creating private records, note the reference to the namespace inside : dns_config <img src="{{ site.url }}{{ site.baseurl }}/assets/images/tf-carbon-discovery.png"/> And lastly, connecting the aws_ecs_service resource to the service registry: <img src="{{ site.url }}{{ site.baseurl }}/assets/images/tf-carbon-registries.png"/> Alternatives The solution above is no the only one for zero trust solution. There are plenty out there, including as well as many OSS alternatives. Buzzfeed's solution was the choice here for its elegance by remaining a one-stop authentication system that builds on top of Google's OAuth2 solution. Any kind of solution will usually do pretty much the same work, and as long as the concept of security is kept, the rest is implementation details. commercial ones Extending the power of Zero Trust Having the system deployed is a great solution for all things web. But sometimes real-life pop the security bubble; in some cases engineers will need to gain access to private resources by SSH, or other protocols (working against a Redis or a PostgreSQL instance). While Working directly against a resource in its protocol is not achievable, we can extend the reach by deploying web interfaces for , -like applications. SSH PGAdmin I would address the engineering culture of accessing private resources in the first place, and how to create a workflow that removes the necessity of such operations, but that's material for another post. In the meantime, let's leave the notion of avoiding it when you can. And if you're serious, you may consider rotating those accessed instances altogether, marking them as once they've been SSH'ed into and automating their removal. Food for thought... contaminated I hope this post helped with grasping the concept of zero trust and real-world implementation. This is something I struggled with when I tried incorporating it in our workflow, so I'm happy to share the experience and the "how-to". If you find any mistakes in the information above, have any questions or comments please ! reach out Thank you for reading 🖤

The Essential Guide to Zero Trust on AWS ECS Fargate

Bitcoin was originally ideated as a peer-to-peer electronic decentralized payment system, based on a public ledger or blockchain. Developers soon realized that the scope of blockchain extended much beyond a modest payment service. viewed it as a platform on which decentralized applications (DApps) could be written using smart contracts, and brought Ethereum to life, which ushered in a new era of blockchain projects. Vitalik Buterin Another application of blockchain technology that has gained ground recently is as distributed data systems. Just like we use centralized data systems like Google Cloud and Amazon AWS, with some optimization, blockchain can be used as a decentralized database. is a blockchain database cloud project and DApp platform, that aims to create a general purpose distributed database for a new digital economy. V Systems The project is based on a brand-new consensus method called Supernode Proof of Stake (SPoS), developed by none other than Sunny King, the brain behind the well-known PoS algorithm. Website: Click here Telegram: Join here V Systems whitepaper: Read here SPoS whitepaper: Read here Bitcoin as Decentralized Database? The obvious question that comes to mind is why can’t the Bitcoin blockchain itself serve as a decentralized database? Well, Bitcoin wasn’t originally created to serve as a database! The data used per transaction is about 100 bytes, and the maximum block size was limited to himself, with new blocks produced every 10 minutes or so. 1 MB by Nakamoto This limitation was deliberately introduced since the increase in data usage would conflict with the system performance. There have been attempts to increase the maximum block size, but all such efforts have led to a lot of ! heart burns and hard forks Another problem here is that in its current form, Bitcoin it is not scalable. Today, the Bitcoin network processes less than 10 transactions per second (TPS). With every transaction, each node in the network has to validate the new blockchain state in its entirety. If data usage is increased, it would either require an upgrade of all the nodes, or result in a heavy decrease in the already-low system throughput. Scaling efforts such a and , unfortunately, have had little impact. Lightning Network SegWit The Problem of PoW Bitcoin’s chosen consensus algorithm is , or PoW. Nodes in the Bitcoin blockchain (called ) solve cryptographic puzzles to validate transactions and create new blocks, keeping the network secure in the process. Proof of Work miners Computation power is expended during this process, and the miner who solves the puzzle first is rewarded with newly Bitcoin. The with time; in other words, more computation power (or ) is required, leading to more electricity being consumed. mined puzzle solving difficulty increases hash rate While 10 years ago one could mine Bitcoins using literally the cheapest laptop available, today special Application Specific Integrated Circuit (ASIC) processors are needed. In fact, the hash rate of a single ASIC processor is also insufficient today, forcing miners to combine their hardware’s hash rates and form what are called . mining pools This power-consumption is an ever-increasing headache. Currently, the annual energy consumed by Bitcoin miners is around , which is almost the same as Ireland’s power consumption. 22 TWh And with bitcoin mining difficulty increasing with time, this number will only grow. Moreover, the tendency to form mining pools tends to centralize the whole ecosystem, which attacks the fundamental value on which Bitcoin was built. Any mining pool that of hash power can end up modifying the Bitcoin blockchain as per its fancy! accumulates over 51% Enter Sunny King The high energy cost of PoW is a necessary evil, as the huge hash power required to mount a 51% attack is what potentially discourages attackers. However, there have always been voices of dissent against PoW’s wasteful nature. One such voice belongs to . Many people might not be familiar with this name, specially since the person behind this pseudonym maintains a reclusive persona, communicating mainly through public forums. Sunny King King is the developer of the (PoS) consensus algorithm. He is considered to be one of the legends in the blockchain space. In fact, Buterin even referred to him as . , launched in 2012, was the first digital currency to adopt PoS. Proof of Stake “the single most original altcoin developer” Peercoin Today, Neo, EOS, Cardano and a bunch of other crypto-currencies use PoS. And Ethereum is also implementing a move to PoS through the upgrade. Casper In PoS, nodes (called ) deposit (or ) coins to the network, and earn minting fees when they create new blocks. The creator of the next block is chosen in a pseudo-random manner, which depends on the quantity of tokens staked. minters stake This randomization prevents centralization; otherwise the node with the most tokens would always end up being the block creator. The general notion is that greater a node’s stake, more the likelihood that the node would want the network to remain secure. In case a node behaves fraudulently, all the tokens staked by that node are confiscated. 51% attacks in a PoS system would require 51% of all blockchain coins. This would be an extremely costly affair, as any such purchasing activity would pump up the token price. Moreover, since the minting fees earned is proportional to the number of coins staked, there is no added incentive of joining mining pools. And finally, as no energy-extensive hardware is required, PoS is much more energy efficient than PoW. PoS also had had its fair share of issues, such as , but these have been resolved through updates in the algorithm. stake grinding and the nothing-at-stake problem SPoS — the Next Generation of PoS Problems related to code updates are easy to resolve, but when it comes to hardware issues, it becomes a major contention. And that is the nemesis PoS faces today. The increased performance demand from blockchain networks requires nodes with improved hardware. However, all nodes might not have enough incentive to upgrade. This causes the entire network to suffer. Another problem is that although the average block generation time is fixed, an individual block might actually take much longer. It is preferable to keep the block generation constant to ensure steady system performance. These issues motivated Sunny King to develop the SPoS algorithm. While PoS allows any computer to mint coins, SPoS requires with much higher memory, bandwidth and processing capacity. Supernodes can process transactions much faster than ordinary nodes, making SPoS much more scalable. supernodes Ordinary nodes can their coins to a supernode, which in turn stakes these coins to earn minting rewards. The rewards are then proportionately distributed among the stake owners. Since minting is done only by supernodes, a constant minting interval can be maintained here. Typically, 60 minting slots are provided each minute, and a supernode has to own a minting slot before minting a new block. lease Contention of minting slot by challenger supernodes is also allowed. This redundancy ensures that system performance is not hampered if some of the supernodes suddenly malfunction. This idea of leasing coins (also called or ) originally came from the Peercoin days, and involved 2 separate keys — a and a . cold minting cold staking minting key spending key The minting key remains online, allowing the minter to sign the newly block minted; the spending key, which actually ‘owns’ the stake, is kept offline safely. This allows nodes to lease their coins without giving up on ownership, but this also encourages the creation of mining pools. This is actually one of the biggest arguments against SPoS today as well. King’s solution to this plight involves providing to all supernodes. Stake owners will tend to lease coins to supernodes which pay more, and this additional lease will lower that particular supernode’s lease rate due to its constant minting output. equal minting rights This mechanism maintains a balance between the lease rates of all supernodes. The hardware requirement of all supernodes is also standardized through community effort, which ensures that no supernode ends up being more powerful than others. SPoS also implements what is known as , where both minters and stake owners can spend or transfer the staked coins whenever they want to. stake liquidity This encourages more nodes to participate in the network, increasing overall security. On the downside, this can lead to the , where a stake owner might try to move the stake around rapidly to claim multiple minting slots. busy contention attack To counter this, an of the account is used when bidding for minting slots, forcing the stake to stay in the account for a certain minimum amount of time. average minting balance Introducing V Systems On 11th Jan, 2019, Sunny King V Systems as the first project to implement SPoS. King has been associated with this project for over a year now, in the capacity of Chief Architect. introduced Their primary goal is to be a on which new blockchains and blockchain applications can be developed at a low cost. distributed database infrastructure They believe that the future of blockchain entails multiple application-specific blockchains, instead of a single blockchain to rule them all. A single blockchain will suffer from scalability limitation, provide no application-wise isolation, and hinder the proper utilization of resources when sharing resources over multiple applications. V Systems will provide custom blockchain solutions for organizations through their , and for developers to create blockchains and DApps instantly, without worrying about complicated time-consuming codes. decentralized cloud platform user-friendly modular development platforms Thanks to SPoS, their platform is . Supernodes will be provided enough incentive to constantly upgrade hardware as required, to support large scale growth of DApps. highly scalable and low-cost V Systems is also working on , as the current breed is difficult to scale and lack security. Their main-net will launch the smart contract and DApps development platform functions later this year. next generation smart contracts For now, they will support Ethereum and EOS smart contracts. will also be supported on their decentralized database platform, with a full privacy protection layer for smart contracts, ensuring that the blockchain is transparent but data remains private. Enterprise DApps Finally, V Systems’ long term vision also includes a , which will include browser support for mobile phone users. decentralized mobile internet network (VSYS Function Roadmap) The V Systems shows that new blocks are minted every 4 seconds. is the native currency of their blockchain. The total coin supply is around 5.14 billion. They are used for paying transaction fees on the network, as well as for leasing and minting. blockchain explorer VSYS Each transaction on the blockchain leads to burning of VSYS and a subsequent deflation. Payments for accessing DApps on the V Systems network, and utilizing resources on the decentralized cloud database, will also be done through VSYS coins. On 27th March, 2019, Hong Kong based ZB/BW/ZBG exchanges co-launched the sale of VSYS on their project launchpad platforms. Over 300,000 KYC users participated in the sale, which got over in less than 10 seconds. VSYS is of the launchpad price in , as on 18th April, 2019. , whose current market cap is nearly 5b USD, is probably their biggest competitor in the blockchain space. trading at ~6x exchanges worldwide EOS Minting on V Systems Supernode Network V Systems has in operation now, and a handful of backup supernodes. New supernodes get listed in the backup section, and if they manage to get a large amount of leased coins, they get promoted to active supernodes. 15 supernodes As explained earlier, when users lease their coins to supernodes, their average minting balance (AMB) increases, such that they can contend for minting slots and earn minting rewards. The supernodes keep a certain portion of the rewards as hardware maintenance fees, and distribute the rest to the users. A point to note here is that supernodes with 100% capacity will not provide users with minting rewards. (VSYS Economy Model) In order to to a supernode, users will first have to create a . Once a wallet is created, copy the address of the supernode of your choice, go the ‘Leasing’ section of your wallet webpage, and enter the details as required. lease coins V Wallet This section is extremely easy and intuitive to navigate, and even first time users should have no difficulty at all. In case additional help is here, some explainer videos can be found in their official . Cancelling of lease can also be done through the same page. Youtube channel Most supernodes actually start giving out rewards once duration is complete. In simple words, users will start getting rewards after roughly 4 days (or 86,400 blocks to be precise) from the time the lease transaction was completed. coin age Parting Thoughts After more than a year in crypto exile, Sunny King is leading a of blockchain developers to reduce the technical barriers and entry cost of blockchain technology. have high communication costs, are prone to hacking, and are susceptible to single-point failures. team Centrally hosted databases On the other hand, distributed database systems have high concurrency, are customizable, have high data security, and other added advantages. The main roadblock to blockchain based database systems today is the low network throughput. With their SPoS consensus algorithm, V Systems promises to change that, and make blockchain technology more accessible to developers.

V Systems — Decentralized Blockchain Database and DApp Platform

We have had so many great projects this year that it was exceedingly difficult to narrow it down to just ten of our favorite projects. A sincere thank you to all of our clients who entrusted us with your infographics this year — we thoroughly enjoyed all of the projects we did, even though many of our favorites aren’t on this list. Here are the best infographics of 2018 (Here are the best from ). 2017 2016 2015 2014 2013 2012 2011 2010 1. The Art And Science Of Delegation Source: Featured On , , and Scaletime Entrepreneur Tech Republic Small Business Trends 2. How Does Amazon Make Its Money? Source: Featured On , , , and Sellbrite Business Insider Big Commerce Tech Republic Visual Capitalist 3. The Future Of Augmented Reality Source: Featured On , , , and Lumus Vision PC Mag RisMedia Entrepreneur Small Business Trends 4. The Art And Science Of Networking Source: Featured On , , , and NetworkWise Entrepreneur Social Media Today The Ladders Website Magazine 5. The Business Of Hemp Source: Featured On , , , and Popular CBD Brands Yahoo Finance Houston Chronicle Entrepreneur Benzinga 6. Habits of People Who Trust Their Intuition Source: Featured On , , , and Project Management Degrees Inc Connecticut Post Entrepreneur Stamford Advocate 7. How Blockchain Will Rebuild The World Source: Featured On , , , and Opinion Blockchain BetaNews HackerNoon CMS Wire SiteProNews 8. Do Your State Laws Protect You? Source: Featured On , , , and Digital Guardian Yahoo Finance Morningstar GovTech Security Boulevard 9. The Business Of Cannabis Source: Featured On , , , and Business Student Black Enterprise The Fresh Toast Green Entrepreneur Benzinga 10. AI: The Dark Side Versus A Force For Good Source: Featured On , , , and Noodle.ai PCMag ZeroHedge BetaNews Techaeris This post originally appeared on NowSourcing

10 Best Infographics Of 2018

Many people think networking is just exchanging business cards and calling it a day, but at it’s core networking is really about building relationships. Humans are, by nature, social creatures and that innate instinct to be social penetrates into our professional lives. Building lasting and valuable professional relationships is just as rewarding as building personal relationships, in addition to the possibility of unique opportunities for professional growth. Everything you know about networking is probably wrong. Often believed to be merely a tool for landing a job or client, there’s more to networking than just handshaking and new Linkedin connections. Smart professionals know the value of networking skills and put those skills to good use. Business leaders use networking to develop relationships with employees on every level, scientists use networking as a way to enter into the world of research grants, and even musicians and music producers use networking to make vital industry contacts. We often think of networking only in professional terms, but the truth is we network every day. Take a look at this for more on the art and science of networking, making and managing new contacts, and using your networking skills to their highest potential. infographic from Networkwise image credit: NetWorkWise

The Art and Science of Hacking Your Network

Food Governance is Imperative for Transparency Over the past decade, the distinction between organic and conventional food has drawn a more discerning eye from consumers. From the farm to the table, food supply chains have grown in complexity and become subjected to ongoing pressures related to global compensation, regulatory controls and the ever-changing interests of customers. But instead of focusing on organic foods in general, people spend more time trying to figure out various interpretations of “organic,” “farm-raised” and “grass-fed” through the eyes of the Food and Drug Administration. The FDA’s increased oversight of associated track-and-trace initiatives demonstrates its commitment to preserving the quality and safety of food and mitigating any risks associated with sourcing. As effective and entrenched as the FDA is, it needs an additional layer of support that a service like blockchain-powered governance can provide. While the government and, to a lesser extent, advocacy groups, each verify food safety for consumers, blockchain’s supervision is different. It represents an independent third party that injects transparency into supply chains that governing bodies can’t match. Why Transparency Matters A recent slew of controversies has cast a shadow over the food industry. For instance, reports in 2014 and 2015 suggested that several U.S. vendors — including names like Safeway, Walmart, Kroger and Red Lobster — were selling seafood . harvested and processed by forced labor Even more troubling are the rampant reports of E. coli from romaine lettuce and various outbreaks of salmonella linked to turkey and raw chicken. Since 2015, because of multiple problems related to its foods. Chipotle has lost more than 46% of its market capitalization To instill a sense of security in the general public, various corporations pledged to address these problems by prioritizing stronger supplier language. Delivering on these promises has proven to be much harder, and until now, retailers haven’t had the tools at their disposal to combat these gaffes. Many modern companies order products from specific providers of origin, but it’s extremely difficult for any company to ensure that every product was sourced with complete integrity. Furthermore, it is challenging to deal with the high prevalence of fraud. If companies are willing to enslave workers to perform rigorous tasks, they are most likely willing to falsify documents pertaining to the origin of products. This lack of clarity into sourcing practices means siloed food chains will continue to wreak havoc on consumer health and corporate credibility. Blockchain and food governance can eliminate both concerns, though. What’s to Gain from Blockchain The absence of transparency in the food supply chain is notable for a number of reasons. Perhaps the biggest concern is the inability of some technological solutions to identify problems and determine the source of breakdowns. With blockchain, industry vendors can define, audit and collaborate on food safety standards. The platforms can connect with existing legacy systems to monitor food supply behavior, streamline compliance management, and analyze internet of things data. Bringing these processes under one umbrella creates a foundation for food supply chains to grow and evolve, which should give peace of mind to vendors and customers. With this information available, vendors can build proactive strategies to stave off recalls and have processes in place should an incident occur. The FDA has loose guidelines in place for integrity and sourcing issues, but the Food Safety Modernization Act looks to improve those by directing the FDA to increase its efforts regarding traceability. The FDA must begin these efforts by running some traceability pilot projects. Blockchain also would separate transforming and processing events into two sets of records: one for tracking inputs and another for tracking outputs. Accurately tracking data such as shipped and received items, quantities and lot numbers can help companies better track produce during every stage of the process. Food vendors must be able to write and share information across an expanding network of trading partners. Blockchain architecture can bring similar networkwide data-sharing benefits to food integrity governance. Where Governance as a Service might fall short Unfortunately, numerous providers only concern themselves with the bottom line. They know their actions aren’t entirely ethical, but the profits they make far outweigh any potential fines or legal issues. If the penalties were to exceed the profits, maybe vendors would be less likely to send out harmful products knowingly. Under the new set of standards, companies are subject to criminal and civil punishments for adulterating or misbranding any product. The Federal Food, Drug, and Cosmetic Act of 1938 as anything that has been prepared, packed or held under unsanitary conditions that could cause it to become contaminated with filth or potentially injure the health of consumers. Under new regulations, liable parties are subject to as much as a felony conviction. defines adulterated foods may provide numerous benefits for certain types of supply chains, but it is not quite ready for mass adoption. Pilot tests have not adequately proven how truly valuable blockchain technology is to the supply chain sector. While blockchain has been unable to capture mass data across many untrusted parties, there are other ways to deliver full transparency and traceability to food supply chains. Blockchain technology The true costs of developing and running a blockchain are not clear, and there is a substantial gap between blockchain’s current capabilities and the enormous capacity needed for food supply chains. Although it’s not immediately apparent how food governance as a service will look in the coming months or years, business leaders should consider the benefits of increased transparency in this sector and continue to push toward it. <a href="https://medium.com/media/3c851dac986ab6dbb2d1aaa91205a8eb/href">https://medium.com/media/3c851dac986ab6dbb2d1aaa91205a8eb/href</a>

Food governance is imperative for transparency

Cryptographic Ransomware Encryption Detection: Survey: Detection of Encryption

Cryptographic Ransomware Encryption Detection: Survey: Author's Declaration

Minimal Knowledge PT-AE Attacks on Black-Box Speaker Recognition Models

Characterizing Cable News Bias: Related Research You Should Know About

Get to know RemotiveBroker’s gRPC API and how it simplifies prototyping, building & testing automotive software. Build software the way you want and in the programming language of your choice. We make things easier with a Python wrapper and the gRPC stubs available in a public repo on our GitHub. Get stuff done with our gRPC API Want to make a quick prototype using Python? Interested in Rust? The RemotiveBroker gRPC API can be used to read and write vehicle signal data in your language of choice. This means that you can use the tools you prefer to quickly build applications that depend on real vehicle signal data. Given a simple configuration and a signal database file, you can get to work right away with recorded data or inside a physical vehicle with live data. Use the same API regardless if you are working with recorded or live data, write your application once and test it on your desktop and inside a vehicle! You can reuse previously recorded drive cycles, e.g. in a deterministic ECU testing setup or when prototyping graphical user interfaces. Once you are satisfied with your work you can, in a true shift-left spirit, bring it to a test rig or physical vehicle knowing that the code has been tested. Paired with our collaboration platform, RemotiveCloud, you can quickly scale up your development efforts with multiple virtualized RemotiveBrokers! Get started with three lines of code Start a RemotiveBroker with three lines of code: $ git clone https://github.com/remotivelabs/remotivebroker-bootstrap.git
$ cd remotivebroker-bootstrap
$ docker-compose up -d Try our free 3-minute demo or check out some of our stuff on Github, e.g the APIs, simple samples, ProtoPie integration) and go to the repo for running the bootstrap RemotiveBroker on your desktop. What is a RemotiveBroker? The RemotiveBroker is a flexible developer tool that fit into most setups. it exposes vehicle signal data via a pub/sub gRPC API. We support the most common vehicle networks like CAN, Flexray, LIN, and Automotive Ethernet – enabled by .dbx, .xml (fibex), .ldf and .arxml. We also proved E2E Protection. Make it even easier with API wrappers and gRPC stubs We have a public repo for our wrappers and stubs. Anyone is welcome to submit a pull request with a wrapper in their favorite language, get started with our gRPC proto files. Our ambition is to have wrappers and stubs/clients available for everyone. Advantages of gRPC Given a simple configuration, the RemotiveBroker will expose a gRPC API that puts you in control. With the broad language support that gRPC has you can use what you prefer, e.g Node.js, Ruby, C# or Kotlin. gRPC leverages HTTP/2 and a binary message format, this helps to reduce network bandwidth and decrease latency. This allows our RemotiveBroker to send large amounts of data in real-time, like in the case of high-speed CAN & CAN-FD or FlexRay. Python wrapper We have a Python wrapper API for a subset of the RemotiveBroker API to make it even easier to build applications. It is also available for easy installation through the Python Package Index. This wrapper API makes it easier to perform common operations like connecting to a RemotiveBroker and setting up vehicle signal data subscriptions. Connect to a RemotiveBroker and set up a signal subscription: # Connect to RemotiveBroker
client = Client()
client.on_connect = lambda c: print(f"Yay! - connected as {c.client_id} to {c.url}")
client.on_signals = lambda signals: print(signals.to_json())
client.connect(url="http://localhost:50051")

subscription = client.subscribe(
signal_names=["Vehicle.Speed"],
namespaces=["vss"],
changed_values_only=False) Typescript and Javascript stubs/clients Since we are working with gRPC-web in our web clients, we have both Typescript and Javascript stubs/clients available for grpc-web. It is also available via npm/yarn. While not as useful as a proper wrapper API, the stubs/clients are required when working with gRPC. However, just looking at the stubs is helpful when exploring the API. Subscribe to frame frequency distribution: // Setup request
const config = new FramesDistributionConfig()
const namespace = new NameSpace()namespace.setName(namespaceName)
config.setNamespace(namespace)

// Subscribe
this._frameDistributionStream =  
this._networkServiceClient.subscribeToFramesDistribution(config) Our tooling and APIs are constantly evolving. Follow us on GitHub and LinkedIn to not miss out on more helpful developer content. If you have wishes or thoughts for what we should develop next don’t be a stranger! Get to know RemotiveBroker’s gRPC API and how it simplifies prototyping, building & testing automotive software. Build software the way you want and in the programming language of your choice. We make things easier with a Python wrapper and the gRPC stubs available in a public repo on our GitHub. programming language Get stuff done with our gRPC API Want to make a quick prototype using Python? Interested in Rust? The RemotiveBroker gRPC API can be used to read and write vehicle signal data in your language of choice. This means that you can use the tools you prefer to quickly build applications that depend on real vehicle signal data. Given a simple configuration and a signal database file, you can get to work right away with recorded data or inside a physical vehicle with live data. RemotiveBroker Use the same API regardless if you are working with recorded or live data, write your application once and test it on your desktop and inside a vehicle! You can reuse previously recorded drive cycles, e.g. in a deterministic ECU testing setup or when prototyping graphical user interfaces. Once you are satisfied with your work you can, in a true shift-left spirit, bring it to a test rig or physical vehicle knowing that the code has been tested. Paired with our collaboration platform, RemotiveCloud , you can quickly scale up your development efforts with multiple virtualized RemotiveBrokers! RemotiveCloud Get started with three lines of code Get started with three lines of code Start a RemotiveBroker with three lines of code: $ git clone https://github.com/remotivelabs/remotivebroker-bootstrap.git
$ cd remotivebroker-bootstrap
$ docker-compose up -d $ git clone https://github.com/remotivelabs/remotivebroker-bootstrap.git
$ cd remotivebroker-bootstrap
$ docker-compose up -d Try our free 3-minute demo or check out some of our stuff on Github, e.g the APIs , simple samples , ProtoPie integration ) and go to the repo for running the bootstrap RemotiveBroker on your desktop . free 3-minute demo APIs simple samples ProtoPie integration bootstrap RemotiveBroker on your desktop What is a RemotiveBroker? What is a RemotiveBroker? The RemotiveBroker is a flexible developer tool that fit into most setups. it exposes vehicle signal data via a pub/sub gRPC API. We support the most common vehicle networks like CAN, Flexray, LIN, and Automotive Ethernet – enabled by .dbx, .xml (fibex), .ldf and .arxml. We also proved E2E Protection. Make it even easier with API wrappers and gRPC stubs Make it even easier with API wrappers and gRPC stubs We have a public repo for our wrappers and stubs. Anyone is welcome to submit a pull request with a wrapper in their favorite language, get started with our gRPC proto files. Our ambition is to have wrappers and stubs/clients available for everyone. public repo Advantages of gRPC Advantages of gRPC Given a simple configuration, the RemotiveBroker will expose a gRPC API that puts you in control. With the broad language support that gRPC has you can use what you prefer, e.g Node.js, Ruby, C# or Kotlin. gRPC leverages HTTP/2 and a binary message format, this helps to reduce network bandwidth and decrease latency. This allows our RemotiveBroker to send large amounts of data in real-time, like in the case of high-speed CAN & CAN-FD or FlexRay. Python wrapper Python wrapper We have a Python wrapper API for a subset of the RemotiveBroker API to make it even easier to build applications. It is also available for easy installation through the Python Package Index. This wrapper API makes it easier to perform common operations like connecting to a RemotiveBroker and setting up vehicle signal data subscriptions. RemotiveBroker Python Package Index. Connect to a RemotiveBroker and set up a signal subscription: Connect to a RemotiveBroker and set up a signal subscription: # Connect to RemotiveBroker
client = Client()
client.on_connect = lambda c: print(f"Yay! - connected as {c.client_id} to {c.url}")
client.on_signals = lambda signals: print(signals.to_json())
client.connect(url="http://localhost:50051")

subscription = client.subscribe(
signal_names=["Vehicle.Speed"],
namespaces=["vss"],
changed_values_only=False) # Connect to RemotiveBroker
client = Client()
client.on_connect = lambda c: print(f"Yay! - connected as {c.client_id} to {c.url}")
client.on_signals = lambda signals: print(signals.to_json())
client.connect(url="http://localhost:50051")

subscription = client.subscribe(
signal_names=["Vehicle.Speed"],
namespaces=["vss"],
changed_values_only=False) Typescript and Javascript stubs/clients Typescript and Javascript stubs/clients Since we are working with gRPC-web in our web clients, we have both Typescript and Javascript stubs/clients available for grpc-web. It is also available via npm/yarn . While not as useful as a proper wrapper API, the stubs/clients are required when working with gRPC. However, just looking at the stubs is helpful when exploring the API. npm/yarn Subscribe to frame frequency distribution: Subscribe to frame frequency distribution: // Setup request
const config = new FramesDistributionConfig()
const namespace = new NameSpace()namespace.setName(namespaceName)
config.setNamespace(namespace)

// Subscribe
this._frameDistributionStream =  
this._networkServiceClient.subscribeToFramesDistribution(config) // Setup request
const config = new FramesDistributionConfig()
const namespace = new NameSpace()namespace.setName(namespaceName)
config.setNamespace(namespace)

// Subscribe
this._frameDistributionStream =  
this._networkServiceClient.subscribeToFramesDistribution(config) Our tooling and APIs are constantly evolving. Follow us on GitHub and LinkedIn to not miss out on more helpful developer content. GitHub LinkedIn If you have wishes or thoughts for what we should develop next don’t be a stranger!

Revolutionize Automotive Software Development with RemotiveBroker's gRPC API

RemotiveBroker-এর gRPC API-এর সাহায্যে অটোমোটিভ সফটওয়্যার ডেভেলপমেন্টে বিপ্লব ঘটান

Revolutionieren Sie die Entwicklung von Automobilsoftware mit der gRPC-API von RemotiveBroker

Revolucione el desarrollo de software automotriz con la API gRPC de RemotiveBroker

Révolutionnez le développement de logiciels automobiles avec l'API gRPC de RemotiveBroker

रिमोटिवब्रोकर के gRPC API के साथ ऑटोमोटिव सॉफ्टवेयर विकास में क्रांतिकारी बदलाव लाएँ

RemotiveBroker の gRPC API で自動車ソフトウェア開発に革命を起こす

RemotiveBroker의 gRPC API로 자동차 소프트웨어 개발에 혁명을 일으키세요

Revolucione o desenvolvimento de software automotivo com a API gRPC da RemotiveBroker

Произведите революцию в разработке автомобильного программного обеспечения с помощью gRPC API RemotiveBroker

RemotiveBroker'ın gRPC API'si ile Otomotiv Yazılım Geliştirmede Devrim Yapın

Cách mạng hóa việc phát triển phần mềm ô tô với API gRPC của RemotiveBroker

利用 RemotiveBroker 的 gRPC API 彻底改变汽车软件开发

Stories, News & Mentions about NETWORKWISE

Networkwise’s Stories on HackerNoon