struc2vec is a framework to generate node vector representations on a graph that preserve the structural identity. In contrast to node2vec, that optimizes node embeddings so that nearby nodes in the graph have similar embedding, struc2vec captures the roles of nodes in a graph, even if structurally similar nodes are far apart in the graph. It learns low-dimensional representations for nodes in a graph, generating random walks through a constructed multi-layer graph starting at each graph node. It is useful for machine learning applications where the downstream application is more related with the structural equivalence of the nodes (e.g., it can be used to detect nodes in networks with similar functions, such as interns in the social network of a corporation). struc2vec identifies nodes that play a similar role based solely on the structure of the graph, for example computing the structural identity of individuals in social networks. In particular, struc2vec employs a degree-based method to measure the pairwise structural role similarity, which is then adopted to build the multi-layer graph. Moreover, the distance between the latent representation of nodes is strongly correlated to their structural similarity. The framework contains three optimizations: reducing the length of degree sequences considered, reducing the number of pairwise similarity calculations, and reducing the number of layers in the generated graph. struc2vec follows the intuition that random walks through a graph can be treated as sentences in a corpus. Each node in a graph is treated as an individual word, and short random walk is treated as a sentence. In its final phase, the algorithm employs Gensim's word2vec algorithm to learn embeddings based on biased random walks. Sequences of nodes are fed into a skip-gram or continuous bag of words model and traditional machine-learning techniques for classification can be used. It is considered a useful framework to learn node embeddings based on structural equivalence.
Site-specific browser
A site-specific browser (SSB) is a software application dedicated to accessing pages from a single source (site) on a computer network such as the Internet or a private intranet. SSBs typically simplify the more complex functions of a web browser by excluding the menus, toolbars and browser graphical user interface associated with functions that are external to the workings of a single site. Modern site-specific browsers range from simple browser windows without navigation controls to sophisticated desktop applications built with frameworks like Electron that bundle entire browser engines. This evolution has enabled many popular desktop applications to be built using web technologies, effectively making them advanced site-specific browsers. == History == === Early development === One of the earliest examples of an SSB was MacDICT, a Mac OS 9 application that accessed various websites to define, translate, or find synonyms for words typed into a text box. However, the first general-purpose SSB is considered to be Bubbles, which launched in late 2005 on the Windows platform. Bubbles introduced the term "Site Specific Extensions" for SSB userscripts and created the first SSB JavaScript API. In 2007, Mozilla announced Prism (originally called WebRunner), a project to integrate web applications with the desktop. That same year, Todd Ditchendorf, a former Apple Dashboard engineer, released Fluid for macOS. On 2 September 2008, Google Chrome was released with a built-in "Create application shortcut" feature, bringing SSB functionality to mainstream users. This feature allowed any website to be launched in a separate window without the browser interface. === Modern era === The landscape of site-specific browsers changed dramatically with the introduction of Electron in 2013 (originally called Atom Shell). Electron combined Chromium and Node.js into a single runtime, enabling developers to build desktop applications using web technologies. This framework has since powered applications used by hundreds of millions of users, including Visual Studio Code, Slack, Discord, and Microsoft Teams. In 2015, the concept of Progressive Web Apps (PWAs) was introduced by Google engineers Alex Russell and Frances Berriman, representing a parallel evolution in web-to-desktop technology. While PWAs share similar goals with SSBs, they follow web standards and can be installed directly from browsers. More recently, alternative frameworks like Tauri have emerged, offering significantly smaller application sizes by using the system's native web renderer instead of bundling Chromium. == Technical implementation == Site-specific browsers can be implemented through various approaches: === Browser-based SSBs === The simplest form of SSB is created through browser features that allow websites to run in separate windows without the standard browser interface. Modern Chromium-based browsers offer "Install as app" or "Create shortcut" functionality that creates a dedicated window for a specific website. These SSBs share the browser's underlying engine and resources but operate in isolated windows. === Framework-based SSBs === More sophisticated SSBs are built using application frameworks: Electron: Bundles a complete Chromium browser with Node.js, resulting in applications of 85MB or larger. Each Electron application runs its own browser instance, providing full access to system APIs but consuming significant resources. Tauri: Uses the operating system's native web rendering engine (WebView2 on Windows, WebKit on macOS, and WebKitGTK on Linux), resulting in applications typically 2.5-10MB in size. Other frameworks: Include Neutralino.js (ultra-lightweight using system browser), Wails (Go-based), and the Chromium Embedded Framework (CEF). == Comparison with Progressive Web Apps == While site-specific browsers and Progressive Web Apps (PWAs) share the goal of bringing web content to the desktop, they differ in several key aspects: == Applications == Site-specific browsers have become the foundation for many popular desktop applications: Communication and collaboration: Many modern communication tools are built as SSBs, including Slack, Discord, Microsoft Teams, and WhatsApp Desktop. These applications benefit from web-based development while providing desktop integration. Development tools: Visual Studio Code, used by 73.6% of developers according to Stack Overflow's 2024 survey, is built with Electron, as are Atom and GitHub Desktop. Productivity software: Applications like Notion, Obsidian, and various project management tools use SSB technology to provide consistent experiences across platforms. Security and Privacy: Web browsers can be modified to only have access to a single site, in order to protect the security and privacy of the user via compartmentalization == Security and performance == === Memory usage === Framework-based SSBs, particularly those using Electron, are known for high memory consumption. Studies show Electron applications typically use 120-300MB at baseline, with complex applications consuming significantly more. This is approximately 5-10 times more memory than equivalent native applications. === Security considerations === SSBs can provide security benefits through process isolation, where each application runs in its own sandboxed environment. However, bundling an entire browser engine also means each application must be updated independently to patch security vulnerabilities. Research presented at the Network and Distributed System Security (NDSS) Symposium has identified various security challenges specific to Electron applications. === Bundle sizes === The choice of framework significantly impacts application size: Electron applications: 85MB+ (includes full Chromium) Tauri applications: 2.5-10MB (uses system WebView) Browser-based SSBs: No additional download (uses existing browser) == Software == === Browser support === Most modern browsers provide some form of SSB functionality: Chromium-based browsers (Google Chrome, Microsoft Edge, Brave, Opera, Vivaldi): "Install as app" or "Create shortcut" feature Safari: "Add to Dock" feature in macOS Sonoma (2023) Firefox: Removed SSB support in December 2020 (version 85) GNOME Web: "Install Site as Web Application" feature === Standalone tools === ==== Active ==== WebCatalog (Windows, macOS, Linux) – Manages multiple SSBs with isolated storage Fluid (macOS) – Pioneering SSB creator for Mac Unite (macOS) – Creates SSBs with customization options Coherence X (macOS) – Advanced SSB creation tool Pake (cross-platform) – Open-source SSB creator Wavebox (cross-platform) – Workspace browser with SSB features ==== Discontinued ==== Mozilla Prism – Cross-platform SSB creator (discontinued 2011) Nativefier – Command-line SSB creator (discontinued 2023) Epichrome – macOS SSB creator (discontinued 2021) === Development frameworks === Electron – Most popular framework, bundles Chromium and Node.js Tauri – Rust-based framework using system WebView Chromium Embedded Framework (CEF) – C++ library for embedding Chromium Neutralino.js – Lightweight framework using system browser Wails – Go-based framework for web frontends
Forking lemma
The forking lemma is any of a number of related lemmas in cryptography research. The lemma states that if an adversary (typically a probabilistic Turing machine), on inputs drawn from some distribution, produces an output that has some property with non-negligible probability, then with non-negligible probability, if the adversary is re-run on new inputs but with the same random tape, its second output will also have the property. This concept was first used by David Pointcheval and Jacques Stern in "Security proofs for signature schemes," published in the proceedings of Eurocrypt 1996. In their paper, the forking lemma is specified in terms of an adversary that attacks a digital signature scheme instantiated in the random oracle model. They show that if an adversary can forge a signature with non-negligible probability, then there is a non-negligible probability that the same adversary with the same random tape can create a second forgery in an attack with a different random oracle. The forking lemma was later generalized by Mihir Bellare and Gregory Neven. The forking lemma has been used and further generalized to prove the security of a variety of digital signature schemes and other random-oracle based cryptographic constructions. == Statement of the lemma == The generalized version of the lemma is stated as follows. Let A be a probabilistic algorithm, with inputs (x, h1, ..., hq; r) that outputs a pair (J, y), where r refers to the random tape of A (that is, the random choices A will make). Suppose further that IG is a probability distribution from which x is drawn, and that H is a set of size h from which each of the hi values are drawn according to the uniform distribution. Let acc be the probability that on inputs distributed as described, the J output by A is greater than or equal to 1. We can then define a "forking algorithm" FA that proceeds as follows, on input x: Pick a random tape r for A. Pick h1, ..., hq uniformly from H. Run A on input (x, h1, ..., hq; r) to produce (J, y). If J = 0, then return (0, 0, 0). Pick h'J, ..., h'q uniformly from H. Run A on input (x, h1, ..., hJ−1, h'J, ..., h'q; r) to produce (J', y'). If J' = J and hJ ≠ h'J then return (1, y, y'), otherwise, return (0, 0, 0). Let frk be the probability that FA outputs a triple starting with 1, given an input x chosen randomly from IG. Then frk ≥ acc ⋅ ( acc q − 1 h ) . {\displaystyle {\text{frk}}\geq {\text{acc}}\cdot \left({\frac {\text{acc}}{q}}-{\frac {1}{h}}\right).} === Intuition === The idea here is to think of A as running two times in related executions, where the process "forks" at a certain point, when some but not all of the input has been examined. In the alternate version, the remaining inputs are re-generated but are generated in the normal way. The point at which the process forks may be something we only want to decide later, possibly based on the behavior of A the first time around: this is why the lemma statement chooses the branching point (J) based on the output of A. The requirement that hJ ≠ h'J is a technical one required by many uses of the lemma. (Note that since both hJ and h'J are chosen randomly from H, then if h is large, as is usually the case, the probability of the two values not being distinct is extremely small.) === Example === For example, let A be an algorithm for breaking a digital signature scheme in the random oracle model. Then x would be the public parameters (including the public key) A is attacking, and hi would be the output of the random oracle on its ith distinct input. The forking lemma is of use when it would be possible, given two different random signatures of the same message, to solve some underlying hard problem. An adversary that forges once, however, gives rise to one that forges twice on the same message with non-negligible probability through the forking lemma. When A attempts to forge on a message m, we consider the output of A to be (J, y) where y is the forgery, and J is such that m was the Jth unique query to the random oracle (it may be assumed that A will query m at some point, if A is to be successful with non-negligible probability). (If A outputs an incorrect forgery, we consider the output to be (0, y).) By the forking lemma, the probability (frk) of obtaining two good forgeries y and y' on the same message but with different random oracle outputs (that is, with hJ ≠ h'J) is non-negligible when acc is also non-negligible. This allows us to prove that if the underlying hard problem is indeed hard, then no adversary can forge signatures. This is the essence of the proof given by Pointcheval and Stern for a modified ElGamal signature scheme against an adaptive adversary. == Known issues with application of forking lemma == The reduction provided by the forking lemma is not tight. Pointcheval and Stern proposed security arguments for Digital Signatures and Blind Signature using Forking Lemma. Claus P. Schnorr provided an attack on blind Schnorr signatures schemes, with more than p o l y l o g ( n ) {\displaystyle polylog(n)} concurrent executions (the case studied and proven secure by Pointcheval and Stern). A polynomial-time attack, for Ω ( n ) {\displaystyle \Omega (n)} concurrent executions, was shown in 2020 by Benhamouda, Lepoint, Raykova, and Orrù. Schnorr also suggested enhancements for securing blind signatures schemes based on discrete logarithm problem.
Client-side encryption
Client-side encryption is the cryptographic technique of encrypting data on the sender's side, before it is transmitted to a server such as a cloud storage service. Client-side encryption features an encryption key that is not available to the service provider, making it difficult or impossible for service providers to decrypt hosted data. Client-side encryption allows for the creation of applications whose providers cannot access the data its users have stored, thus offering a high level of privacy. Applications utilizing client-side encryption are sometimes marketed under the misleading or incorrect term "zero-knowledge", but this is a misnomer, as the term zero-knowledge describes something entirely different in the context of cryptography. == Details == Client-side encryption seeks to eliminate the potential for data to be viewed by service providers (or third parties that compel service providers to deliver access to data), client-side encryption ensures that data and files that are stored in the cloud can only be viewed on the client-side of the exchange. This prevents data loss and the unauthorized disclosure of private or personal files, providing increased peace of mind for its users. Current recommendations by industry professionals as well as academic scholars offer great vocal support for developers to include client-side encryption to protect the confidentiality and integrity of information. === Examples of services that use client-side encryption by default === Tresorit MEGA Cryptee Cryptomator === Examples of services that optionally support client-side encryption === Apple iCloud offers optional client-side encryption when "Advanced Data Protection for iCloud" is enabled. Google Drive, Google Docs, Google Meet, Google Calendar, and Gmail — However, as of Jul 2024, optional client-side encryption features are only available to paid users. === Examples of services that do not support client-side encryption === Dropbox === Examples of client-side encrypted services that no longer exist === SpiderOak Backup
Tropical cryptography
In tropical analysis, tropical cryptography refers to the study of a class of cryptographic protocols built upon tropical algebras. In many cases, tropical cryptographic schemes have arisen from adapting classical (non-tropical) schemes to instead rely on tropical algebras. The case for the use of tropical algebras in cryptography rests on at least two key features of tropical mathematics: in the tropical world, there is no classical multiplication (a computationally expensive operation), and the problem of solving systems of tropical polynomial equations has been shown to be NP-hard. == Basic Definitions == The key mathematical object at the heart of tropical cryptography is the tropical semiring ( R ∪ { ∞ } , ⊕ , ⊗ ) {\displaystyle (\mathbb {R} \cup \{\infty \},\oplus ,\otimes )} (also known as the min-plus algebra), or a generalization thereof. The operations are defined as follows for x , y ∈ R ∪ { ∞ } {\displaystyle x,y\in \mathbb {R} \cup \{\infty \}} : x ⊕ y = min { x , y } {\displaystyle x\oplus y=\min\{x,y\}} x ⊗ y = x + y {\displaystyle x\otimes y=x+y} It is easily verified that with ∞ {\displaystyle \infty } as the additive identity, these binary operations on R ∪ { ∞ } {\displaystyle \mathbb {R} \cup \{\infty \}} form a semiring.
Floyd–Steinberg dithering
Floyd–Steinberg dithering is an image dithering algorithm first published in 1976 by Robert W. Floyd and Louis Steinberg. It is commonly used by image manipulation software, for example, when converting an image from a Truecolor 24-bit PNG format into a GIF format, which is restricted to a maximum of 256 colors. == Implementation == The algorithm achieves dithering using error diffusion, meaning it pushes (adds) the residual quantization error of a pixel onto its neighboring pixels, to be quantized after. It spreads the debt out according to the distribution (shown as a map of the neighboring pixels): [ ∗ 7 16 … … 3 16 5 16 1 16 … ] {\displaystyle {\begin{bmatrix}&&&{\frac {\displaystyle 7}{\displaystyle 16}}&\ldots \\\ldots &{\frac {\displaystyle 3}{\displaystyle 16}}&{\frac {\displaystyle 5}{\displaystyle 16}}&{\frac {\displaystyle 1}{\displaystyle 16}}&\ldots \\\end{bmatrix}}} The pixel indicated with a star () indicates the pixel currently being scanned, and the blank pixels are the previously scanned pixels. The specific values (7/16, 3/16, 5/16, 1/16) were originally found by trial-and-error, "guided by the desire to have a region of desired density 0.5 come out as a checkerboard pattern". The algorithm scans the image from left to right, top to bottom, quantizing pixel values one by one. Each time, the quantization error is transferred to the neighboring pixels, while not affecting the pixels that already have been quantized. Hence, if a number of pixels have been rounded downwards, it becomes more likely that the next pixel is rounded upwards, such that on average, the quantization error is close to zero. The diffusion coefficients have the property that if the original pixel values are exactly halfway in between the nearest available colors, the dithered result is a checkerboard pattern. For example, 50% grey data could be dithered as a black-and-white checkerboard pattern. For optimal dithering, the counting of quantization errors should be in sufficient accuracy to prevent rounding errors from affecting the result. For correct results, all values should be linearized first, rather than operating directly on sRGB values as is common for images stored on computers. In some implementations, the horizontal direction of scan alternates between lines; this is called "serpentine scanning" or boustrophedon transform dithering. The algorithm described above is in the following pseudocode. This works for any approximately linear encoding of pixel values, such as 8-bit integers, 16-bit integers or real numbers in the range [0, 1]. for each y from top to bottom do for each x from left to right do oldpixel := pixels[x][y] newpixel := find_closest_palette_color(oldpixel) pixels[x][y] := newpixel quant_error := oldpixel - newpixel pixels[x + 1][y ] := pixels[x + 1][y ] + quant_error × 7 / 16 pixels[x - 1][y + 1] := pixels[x - 1][y + 1] + quant_error × 3 / 16 pixels[x ][y + 1] := pixels[x ][y + 1] + quant_error × 5 / 16 pixels[x + 1][y + 1] := pixels[x + 1][y + 1] + quant_error × 1 / 16 When converting grayscale pixel values from a high to a low bit depth (e.g. 8-bit grayscale to 1-bit black-and-white), find_closest_palette_color() may perform just a simple rounding, for example: find_closest_palette_color(oldpixel) = round(oldpixel / 255) The pseudocode can result in pixel values exceeding the valid values (such as greater than 255 in 8-bit grayscale images). Such values should ideally be handled by the find_closest_palette_color() function, rather than clipping the intermediate values, since a subsequent error may bring the value back into range. However, if fixed-width integers are used, wrapping of intermediate values would cause inversion of black and white, and so should be avoided. The find_closest_palette_color() implementation is nontrivial for a palette that is not evenly distributed, however small inaccuracies in selecting the correct palette color have minimal visual impact due to error being propagated to future pixels. A nearest neighbor search in 3D is frequently used.
Messaging Layer Security
Messaging Layer Security (MLS) is a security layer for end-to-end encrypted messages. It is maintained by the MLS working group of the Internet Engineering Task Force (IETF), and is designed to provide an efficient and practical security mechanism for groups as large as 50,000 and for those who access chat systems from multiple devices. == Security properties == Security properties of MLS include message confidentiality, message integrity and authentication, membership authentication, asynchronicity, forward secrecy, post-compromise security, and scalability. == History == The idea was born in 2016 and first discussed in an unofficial meeting during IETF 96 in Berlin with attendees from Wire, Mozilla and Cisco. Initial ideas were based on pairwise encryption for secure 1:1 and group communication. In 2017, an academic paper introducing Asynchronous Ratcheting Trees was published by the University of Oxford and Facebook setting the focus on more efficient encryption schemes. The first BoF took place in February 2018 at IETF 101 in London. The founding members are Mozilla, Facebook, Wire, Google, Twitter, University of Oxford, and INRIA. On March 29, 2023, the IETF approved publication of Messaging Layer Security (MLS) as a new standard. It was officially published on July 19, 2023. At that time, Google announced it intended to add MLS to the end to end encryption used by Google Messages over Rich Communication Services (RCS). In March 2025, the GSMA announced the Universal Profile 3.0 standard of RCS would support MLS and Apple announced it would support this RCS standard on Apple Messages. Both Google Messages and Apple Messages began the rollout of MLS E2EE over RCS in May 2026. Matrix is one of the protocols declaring migration to MLS. In 2026, Discord rolled out end-to-end encryption on voice and video calls, using MLS for scalable group key exchanges. Research on adding post-quantum cryptography (PQC) to MLS is ongoing. The IETF has prepared an Internet-Draft using PQC algorithms in MLS. == Implementations ==