Keith "Youngin" George II is a former mixtape DJ, music executive, manager, producer, and technology app director. He has collaborated with Maino, T-Pain, Nas and Soulja Boy, among others. He was instrumental in the launch of social media app and website, Kandiid in 2021 and served as Fliiks App Director of Regional Development. == Career == Keith Anthony George II was born in Upper Heyford, Oxfordshire, England. His father was in the Air Force which exposed him to different cultures and music. He graduated from Allen High School and attended San Antonio College. George's music career began in 2006 as a mixtape DJ working as DJ Youngin Beatz. He performed at various shows and worked with a variety of artists, managers, and music executives. In 2007, George released the mixtape, Untapped market Vol. 1 (Da Underdogz), which featured tracks from artists including Kanye West, Lil Wayne, 50 Cent, Yung Berg, and Nelly. In 2008, he began working with Def Jam executive Sarah Alminawi who was managing Maino at the time. George played a key role in the marketing and promotional success of Maino's single, Hi Hater, which peaked at #8 on Billboard's US Bubbling Under Hot 100 chart. In 2021, George was an advisor and infrastructure head at Kandiid, a social media app which won a W3 Award in 2022. In 2023, he became involved with Fliiks App as Director of Regional Development which earned a Telly Award, two Muse Awards, and a W3 Award in 2025. In 2025, George was a composer and producer on two singles on Sekou Andrews's album, Koumami; The Chosen One: ACT 1 (featuring Lion Babe) and Love Don't Care (featuring Jordin Sparks and Omari Hardwick). In 2025, he was awarded an Atlanta City Proclamation for Philanthropy and Community Leadership for his partnership with Women's International Grail, a nonprofit organization that assists women, single mothers, and low-income families. He also collaborates with local youth programs, creative networks, and minority-owned startups, providing access to mentorship and industry knowledge. == Awards ==
Straight-Through Quality
Straight-Through Quality (STQ) are approaches and outputs of test automation that have quality and deliver business benefit. STQ takes its name from the business concept of straight-through processing (STP). Also acting as a tool and enabler for STP. Traditional techniques for testing and delivery have often required a great deal of manual support and intervention. These approaches are subject to human error, cost of delay and lack of reuse. These also have the negative side-effect of being unable to deliver 'fail-fast' approaches, which have proven popular with Agile practitioners. Previous traditional approaches have been typically expensive where whole silo'ed departments are created within commercial companies to deliver Quality and Deployment alone. Thus STQ as an approach hopes to resolve this problem. == Examples == Tangible examples of STQ approaches in the software industry are present and often known as continuous integration (CI) and continuous delivery (CD). These combined can ensure that software delivery is integrated, automatically tested and ready for automatic delivery at any time. Together CI/CD can enable STQ which can be used as Business output terminology for business users who do not understand the technical complexities of CI/CD.
Futel
Futel is a public arts organization in Portland, Oregon dedicated to preserving and maintaining public telephone hardware and offering free phone and basic information services. Futel was founded by Karl Anderson, a former software engineer, and Elijah St. Clair. == Technology == Karl Anderson stated that one motivation for the project was to explore the idea of urban furniture. Other reasons were to preserve an important part of hacker history, and to salvage and re-use manufactured items at the end of their lifecycle. The original Futel phones were set up in Portland, Oregon. The organization cleans and repurposes old public payphones which are often salvaged from Craigslist or scrappers. Using interface boxes, they are converted into VoIP phones which are made available publicly, with no cost for phone calls. Anderson has said the service runs on "Asterisk and OpenVPN and a lot of scripts." The payphones operate using publicly-available internet connections. The phones have automated phone trees and users can make a call to local social services, to a weather forecast line, or access local transit information. Volunteers act as telephone operators, offering information about the Futel service, or are available for conversation. Users using Futel's phones may also access voicemail boxes. The system has a "wildcard line" where people can listen to samples of audio left on the main voicemail line along with commentary from Anderson and others. == Network == In February 2021, there were 10 Futel phones in Portland and 3 in other cities. Phones were set up in Detroit and Ypsilanti, Michigan, and Long Beach, Washington. The organization has provided free phone service for a Portland-area homeless encampment after receiving funding from the Awesome Foundation. In 2019 the organization reported their phones being used to make 12,000 phone calls. Futel also said their usage went up and not down during the first year of the COVID-19 pandemic when they outfitted their phone kiosks with handwashing stations and used volunteers to keep the phones clean. The project is funded is primarily through grants and is staffed with volunteers. The project has inspired others such as the PhilTel project in Philadelphia and the RandTel project in Randolph, Vermont. Futel publishes a zine called Party Line.
CloudLibrary
CloudLibrary (stylized as "cloudLibrary") is a cloud-based software system through which libraries lend electronic books; it is also the name of the app that users download to access the e-books. CloudLibrary was created in 2011 by 3M as part of its library systems unit as a competitor to OverDrive, Inc.; in 2015 3M sold the North American part of that unit to Bibliotheca Group GmbH, a company founded in 2011 that was funded by One Equity Partners Capital Advisors, a division of JP Morgan Chase. By 2019, Bibliotecha had tried, unsuccessfully, to negotiate with Amazon to add Kindle-ebook compatibility to cloudLibrary - something that, as of then, Amazon had only made available to Overdrive. In that year, cloudLibrary, along with hoopla offered by Midwest Tape, ODILO, and Baker & Taylor’s Axis 360, were the main competitors to the Overdrive and Libby apps offered by OverDrive, Inc. in the library e-book market. In April 2024, Bibliotheca sold cloudLibrary to the nonprofit cooperative OCLC. By that time, cloudLibrary was used by around 500 libraries in around 20 countries in around 50 languages, and was used to lend audiobooks, digital magazines, newspapers, and comics, and streaming media, along with e-books.
Polyfill (programming)
In software development, a polyfill is code that implements a new standard feature of a deployment environment within an old version of that environment that does not natively support the feature. Most often, it refers to JavaScript code that implements an HTML5 or CSS web standard, either an established standard (supported by some browsers) on older browsers, or a proposed standard (not supported by any browsers) on existing browsers. Polyfills are also used in PHP and Python. Polyfills allow web developers to use an API regardless of whether or not it is supported by a browser, and usually with minimal overhead. Typically they first check if a browser supports an API, and use it if available, otherwise using their own implementation. Polyfills themselves use other, more supported features, and thus different polyfills may be needed for different browsers. The term is also used as a verb: polyfilling is providing a polyfill for a feature. == Definition == The term is a neologism, coined by Remy Sharp, who required a word that meant "replicate an API using JavaScript (or Flash or whatever) if the browser doesn’t have it natively" while co-writing the book Introducing HTML5 in 2009. Formally, "a shim is a library that brings a new API to an older environment, using only the means of that environment." Polyfills exactly fit this definition; the term shim was also used for early polyfills. However, to Sharp shim connoted non-transparent APIs and workarounds, such as spacer GIFs for layout, sometimes known as shim.gif, and similar terms such as progressive enhancement and graceful degradation were not appropriate, so he invented a new term. The term is based on the multipurpose filling paste brand Polyfilla, a paste used to cover up cracks and holes in walls, and the meaning "fill in holes (in functionality) in many (poly-) ways." The word has since gained popularity, particularly due to its use by Paul Irish and in Modernizr documentation. The distinction that Sharp makes is: What makes a polyfill different from the techniques we have already, like a shim, is this: if you removed the polyfill script, your code would continue to work, without any changes required in spite of the polyfill being removed. This distinction is not drawn by other authors. At times various other distinctions are drawn between shims, polyfills, and fallbacks, but there are no generally accepted distinctions: most consider polyfills a form of shim. The term polyfiller is also occasionally found. == Examples == === core-js === core-js is one of the most popular JavaScript standard library polyfills. Includes polyfills for ECMAScript up to the latest version of the standard: promises, symbols, collections, iterators, typed arrays, many other features, ECMAScript proposals, some cross-platform WHATWG / W3C features and proposals like URL. You can load only required features or use it without global namespace pollution. It can be integrated with Babel, which allows it to automatically inject required core-js modules into your code. === html5shiv === In IE versions prior to 9, unknown HTML elements like
BeyondCorp
BeyondCorp is an implementation of zero-trust computer security concepts creating a zero trust network. It is created by Google. == Background == It was created in response to the 2009 Operation Aurora. An open source implementation inspired by Google's research paper on an access proxy is known as "transcend". Google documented its Zero Trust journey from 2014 to 2018 through a series of articles in the journal ;login:. Google called their ZT network "BeyondCorp". Google implemented a Zero Trust architecture on a large scale, and relied on user and device credentials, regardless of location. Data was encrypted and protected from managed devices. Unmanaged devices, such as BYOD, were not given access to the BeyondCorp resources. == Design and technology == BeyondCorp utilized a zero trust security model, which is a relatively new security model that it assumes that all devices and users are potentially compromised. This is in contrast to traditional security models, which rely on firewalls and other perimeter defenses to protect sensitive data. === Trust === The corporate network grants no inherent trust, and all internal apps are accessed via the BeyondCorp system, regardless of whether the user is in a Google office or working remotely. BeyondCorp is related to Zero Trust architecture as it implements a true Zero Trust network, where all access is granted on identity, device, and authentication, based on robust underlying device and identity data sources. BeyondCorp works by using a number of security policies including authentication, authorization, and access control to ensure that only authorized users can access corporate resources. Authentication verifies the identity of the user, authorization determines whether the user has permission to access the requested resource, and access control policies restrict what the user can do with the resource. ==== Trust Inferrer ==== One of the main components in BeyondCorp's implementation is the Trust Inferrer. The Trust Inferrer is a security component (typically software) that looks at information about a user's device, like a computer or phone, to decide how much it can be trusted to access certain resources like important company documents. The Trust Inferrer checks things like the security of the device, whether it has the right software installed, and if it belongs to an authorized user. Based on all this information, the Trust Inferrer decides what the device can access and what it can't. === Security mechanisms === Unlike traditional VPNs, BeyondCorp's access policies are based on information about a device, its state, and its associated user. BeyondCorp considers both internal networks and external networks to be completely untrusted, and gates access to applications by dynamically asserting and enforcing levels, or “tiers,” of access. === Device Inventory Database === BeyondCorp utilized a Device Inventory Database and Device Identity that uniquely identifies a device through a digital certificate. Any changes to the device are recorded in the Device Inventory Database. The certificate is used to uniquely identify a device; however, additional information is required to grant access privileges to a resource. === Access Control Engine === Another important component of BeyondCorp's implementation is the Access Control Engine. Think of this as the brain of the Zero Trust architecture. The Access Control Engine is like a traffic cop standing at an intersection. Its job is to make sure that only authorized devices and users are allowed to access specific resources (like files or applications) on the network. It checks the access policy (the rules that say who can access what), the device's state (like whether it has the right software updates or security settings), and the resources being requested. Then it makes a decision on whether to grant or deny access based on all of this information. It helps ensure that only the right people and devices are allowed access to the network, which helps keep things secure. The Access Control Engine utilizes the output from the Trust Inferrer and other data that is fed into its system. == Usage == One of the first things Google did to implement a Zero Trust architecture was to capture and analyze network traffic. The purpose of analyzing the traffic was to build a baseline of what typical network traffic looked like. In doing so, BeyondCorp also discovered unusual, unexpected, and unauthorized traffic. This was very useful because it gave the BeyondCorp engineers critical information that assisted them in reengineering the system in a secure manner. Some of the benefits BeyondCorp realized by adopting a Zero Trust architecture include the ability to allow their employees to work securely from any location. It reduces the risk of data breaches since data and applications are protected and users and devices are constantly being verified. The Zero Trust architecture is scalable and can be adapted to the changing needs of the businesses and their users. Especially relevant in today's work-from-home era, BeyondCorp allows employees to access enterprise resources securely from any location, without the need for traditional VPNs.
HTTP cookie
An HTTP cookie (also called web cookie, Internet cookie, browser cookie, or simply cookie) is a small block of data created by a web server while a user is browsing a website and placed on the user's computer or other device by the user's web browser. Cookies are placed on the device used to access a website, and more than one cookie may be placed on a user's device during a session. Cookies serve useful and sometimes essential functions on the web. They enable web servers to store stateful information (such as items added in the shopping cart in an online store) on the user's device or to track the user's browsing activity (including clicking particular buttons, logging in, or recording which pages were visited in the past). They can also be used to save information that the user previously entered into form fields, such as names, addresses, passwords, and payment card numbers for subsequent use. Authentication cookies are commonly used by web servers to authenticate that a user is logged in, and with which account they are logged in. Without the cookie, users would need to authenticate themselves by logging in on each page containing sensitive information that they wish to access. The security of an authentication cookie generally depends on the security of the issuing website and the user's web browser, and on whether the cookie data is encrypted. Security vulnerabilities may allow a cookie's data to be read by an attacker, used to gain access to user data, or used to gain access (with the user's credentials) to the website to which the cookie belongs (see cross-site scripting and cross-site request forgery for examples). Tracking cookies, and especially third-party tracking cookies, are commonly used as ways to compile long-term records of individuals' browsing histories — a potential privacy concern that prompted European and U.S. lawmakers to take action in 2011. European law requires that all websites targeting European Union member states gain "informed consent" from users before storing non-essential cookies on their device. == Background == === Origin of the name === The term cookie was coined by web-browser programmer Lou Montulli. It was derived from the term magic cookie, which is a packet of data a program receives and sends back unchanged, used by Unix programmers. === History === Magic cookies were already used in computing when computer programmer Lou Montulli had the idea of using them in web communications in June 1994. At the time, he was an employee of Netscape Communications, which was developing an e-commerce application for MCI. Vint Cerf and John Klensin represented MCI in technical discussions with Netscape Communications. MCI did not want its servers to have to retain partial transaction states, which led them to ask Netscape to find a way to store that state in each user's computer instead. Cookies provided a solution to the problem of reliably implementing a virtual shopping cart. Together with John Giannandrea, Montulli wrote the initial Netscape cookie specification the same year. Version 0.9beta of Mosaic Netscape, released on 13 October 1994, supported cookies. The first use of cookies (out of the labs) was checking whether visitors to the Netscape website had already visited the site. Montulli applied for a patent for the cookie technology in 1995, which was granted in 1998. Support for cookies was integrated with Internet Explorer in version 2, released in October 1995. The introduction of cookies was not widely known to the public at the time. In particular, cookies were accepted by default, and users were not notified of their presence. The public learned about cookies after the Financial Times published an article about them on 12 February 1996. In the same year, cookies received a lot of media attention, especially because of potential privacy implications. Cookies were discussed in two U.S. Federal Trade Commission hearings in 1996 and 1997. The development of the formal cookie specifications was already ongoing. In particular, the first discussions about a formal specification started in April 1995 on the www-talk mailing list. A special working group within the Internet Engineering Task Force (IETF) was formed. Two alternative proposals for introducing state in HTTP transactions had been proposed by Brian Behlendorf and David Kristol respectively. But the group, headed by Kristol himself and Lou Montulli, soon decided to use the Netscape specification as a starting point. In February 1996, the working group identified third-party cookies as a considerable privacy threat. The specification produced by the group was eventually published as RFC 2109 in February 1997. It specifies that third-party cookies were either not allowed at all, or at least not enabled by default. At this time, advertising companies were already using third-party cookies. The recommendation about third-party cookies of RFC 2109 was not followed by Netscape and Internet Explorer. RFC 2109 was superseded by RFC 2965 in October 2000. RFC 2965 added a Set-Cookie2 header field, which informally came to be called "RFC 2965-style cookies" as opposed to the original Set-Cookie header field which was called "Netscape-style cookies". Set-Cookie2 was seldom used, however, and was deprecated in RFC 6265 in April 2011 which was written as a definitive specification for cookies as used in the real world. No modern browser recognizes the Set-Cookie2 header field. == Terminology == === Session cookie === A session cookie (also known as an in-memory cookie, transient cookie or non-persistent cookie) exists only in temporary memory while the user navigates a website. Session cookies expire or are deleted when the user closes the web browser. Session cookies are identified by the browser by the absence of an expiration date assigned to them. === Persistent cookie === A persistent cookie expires at a specific date or after a specific length of time. For the persistent cookie's lifespan set by its creator, its information will be transmitted to the server every time the user visits the website that it belongs to, or every time the user views a resource belonging to that website from another website (such as an advertisement). For this reason, persistent cookies are sometimes referred to as tracking cookies because they can be used by advertisers to record information about a user's web browsing habits over an extended period of time. Persistent cookies are also used for reasons such as keeping users logged into their accounts on websites, to avoid re-entering login credentials at every visit. (See § Uses, below.) === Secure cookie === A secure cookie can only be transmitted over an encrypted connection (i.e. HTTPS). They cannot be transmitted over unencrypted connections (i.e. HTTP). This makes the cookie less likely to be exposed to cookie theft via eavesdropping. A cookie is made secure by adding the Secure flag to the cookie. === Http-only cookie === An http-only cookie cannot be accessed by client-side APIs, such as JavaScript. This restriction eliminates the threat of cookie theft via cross-site scripting (XSS). However, the cookie remains vulnerable to cross-site tracing (XST) and cross-site request forgery (CSRF) attacks. A cookie is given this characteristic by adding the HttpOnly flag to the cookie. === Same-site cookie === In 2016 Google Chrome version 51 introduced a new kind of cookie with attribute SameSite with possible values of Strict, Lax or None. With attribute SameSite=Strict, the browsers would only send cookies to a target domain that is the same as the origin domain. This would effectively mitigate cross-site request forgery (CSRF) attacks. With SameSite=Lax, browsers would send cookies with requests to a target domain even it is different from the origin domain, but only for safe requests such as GET (POST is unsafe) and not third-party cookies (inside iframe). Attribute SameSite=None would allow third-party (cross-site) cookies, however, most browsers require secure attribute on SameSite=None cookies. The Same-site cookie is incorporated into a new RFC draft for "Cookies: HTTP State Management Mechanism" to update RFC 6265 (if approved). Chrome, Firefox, and Edge started to support Same-site cookies. The key of rollout is the treatment of existing cookies without the SameSite attribute defined, Chrome has been treating those existing cookies as if SameSite=None, this would let all website/applications run as before. Google intended to change that default to SameSite=Lax in Chrome 80 planned to be released in February 2020, but due to potential for breakage of those applications/websites that rely on third-party/cross-site cookies and COVID-19 circumstances, Google postponed this change to Chrome 84. === Supercookie === A supercookie is a cookie with an origin of a top-level domain (such as .com) or a public suffix (such as .co.uk). Ordinary cookies, by contrast, have an origin of a specific domain name, such as ex