In web development, hydration or rehydration is a technique in which client-side JavaScript converts a web page that is static from the perspective of the web browser, delivered either through static rendering or server-side rendering, into a dynamic web page by attaching event handlers to the HTML elements in the DOM. Because the HTML is pre-rendered on a server, this allows for a fast "first contentful paint" (when useful data is first displayed to the user), but there is a period of time afterward where the page appears to be fully loaded and interactive, but is not until the client-side JavaScript is executed and event handlers have been attached. Frameworks that use hydration include Next.js and Nuxt. React v16.0 introduced a "hydrate" function, which hydrates an element, in its API. == Variations == === Streaming server-side rendering === Streaming server-side rendering allows one to send HTML in chunks that the browser can progressively render as it is received. This can provide a fast first paint and first contentful paint as HTML markup arrives to users faster. === Progressive rehydration === In progressive rehydration, individual pieces of a server-rendered application are “booted up” over time, rather than the current common approach of initializing the entire application at once. This can help reduce the amount of JavaScript required to make pages interactive, since client-side upgrading of low priority parts of the page can be deferred to prevent blocking the main thread. It can also help avoid one of the most common server-side rendering rehydration pitfalls, where a server-rendered DOM tree gets destroyed and then immediately rebuilt – most often because the initial synchronous client-side render required data that wasn't quite ready, perhaps awaiting Promise resolution. === Partial rehydration === Partial rehydration has proven difficult to implement. This approach is an extension of the idea of progressive rehydration, where the individual pieces (components/views/trees) to be progressively rehydrated are analyzed and those with little interactivity or no reactivity are identified. For each of these mostly-static parts, the corresponding JavaScript code is then transformed into inert references and decorative functionality, reducing their client-side footprint to near-zero. The partial hydration approach comes with its own issues and compromises. It poses some interesting challenges for caching, and client-side navigation means it cannot be assumed that server-rendered HTML for inert parts of the application will be available without a full page load. One framework that supports partial rehydration is Elder.js, which is based on Svelte. === Trisomorphic rendering === Trisomorphic rendering is a technique which uses streaming server-side rendering for initial/non-JavaScript navigations, and then uses service workers to take on rendering of HTML for navigations after it has been installed. This can keep cached components and templates up to date and enables SPA-style navigations for rendering new views in the same session. This approach works best when one can share the same templating and routing code between the server, client page, and service worker.
Thermal attack
A thermal attack (aka thermal imaging attack) is an approach that exploits heat traces to uncover the entered credentials. These attacks rely on the phenomenon of heat transfer from one object to another. During authentication, heat transfers from the users' hands to the surface they are interacting with, leaving heat traces behind that can be analyzed using thermal cameras that operate in the far-infrared spectrum. These traces can be recovered and used to reconstruct the passwords. In some cases, the attack can be successful even 30 seconds after the user has authenticated. Thermal attacks can be performed after the victim had authenticated, alleviating the need for in-situ observation attacks (e.g., shoulder surfing attacks) that can be affected by hand occlusions. While smudge attacks can reveal the order of entries of graphical passwords, such as the Android Lock Patterns, thermal attacks can reveal the order of entries even in the case of PINs or alphanumeric passwords. The reason thermal attacks leak information about the order of entry is because keys and buttons that the user touches first lose heat over time, while recently touched ones maintain the heat signature for a longer time. This results in distinguishable heat patterns that can tell the attacker which entry was entered first. Thermal attacks were shown to be effective against plastic keypads, such as the ones used to enter credit card's PINs in supermarkets and restaurants, and on handheld mobile devices such as smartphones and tablets. In their paper published at the Conference on Human Factors in Computing Systems (CHI 2017), Abdelrahman et al. showed that the attack is feasible on today's smartphones. They also proposed some ways to mitigate the attack, such as swiping randomly on the screen to distort the heat traces, or forcing maximum CPU usage for a few seconds. Thermal attacks can also infer passwords from heat traces on keyboards. Researchers at the University of Glasgow showed that attackers who use AI methods can be more effective in performing thermal attacks. Their study presents a new tool called ThermoSecure and evaluates it in two user studies. The results show that ThermoSecure can successfully attack passwords with an average accuracy of 92% to 55%, depending on the length of the password. The effectiveness of thermal attacks also depends on typing behavior and the material of the keycaps. ABS keycaps, which retain heat traces longer, are more vulnerable to thermal attacks. The study also discusses ways to protect against thermal attacks and presents seven potential mitigation approaches. Dr Khamis, who led the development of the technology with Norah Alotaibi and John Williamson, said with thermal imaging cameras more affordable than ever and machine learning becoming more accessible, it was "very likely that people around the world are developing systems along similar lines to ThermoSecure in order to steal passwords". == Thermal Attack Mitigation == === Simple and Practical Measures === One basic and effective way to mitigate thermal attacks is to deliberately create heat noise over the input interface, such as a keypad or keyboard, after entering a password. For instance, placing one's palm over the entire interface for a few seconds after use can obscure the thermal pattern left by the fingers, making it much more difficult for an unauthorized user to interpret the heat traces. === Range of Proposed Strategies === In addition to simple methods, researchers have developed a spectrum of mitigation strategies to counter thermal attacks. These strategies encompass 15 different approaches including: Use of Biometrics: Replacing traditional pin codes or passwords with biometric authentication, such as fingerprint recognition or facial recognition, eliminates the issue of residual heat on keypads. Heating the Interface: Implementing technology to slightly warm up the keypad can effectively neutralize the heat traces left by fingers, preventing thermal cameras from capturing the pattern. Randomizing Key Layouts: Employing dynamic key layouts that change positions every time the interface is used, making it impossible to correlate heat patterns with static input positions. === Technological Intervention on Thermal Cameras === Another avenue for mitigation is to address the issue at the source by modifying thermal cameras. Proposals have been made to develop thermal cameras that can automatically detect vulnerable interfaces such as keyboards or keypads. When these interfaces are detected within the camera's field of view, the camera would be programmed to prevent the user from recording images of them. This solution, however, would require widespread adoption by thermal camera manufacturers. Additionally, the approach is particularly viable for thermal cameras connected to a computing device, such as a smartphone, which can process the images in real time. Many affordable thermal cameras are standalone and do not have connectivity or processing capabilities. However, thermal cameras designed for connection to mobile devices can utilize the smartphone's processing power, making this mitigation approach feasible for such devices.
Web engineering
The World Wide Web has become a major delivery platform for a variety of complex and sophisticated enterprise applications in several domains. In addition to their inherent multifaceted functionality, these Web applications exhibit complex behaviour and place some unique demands on their usability, performance, security, and ability to grow and evolve. However, a vast majority of these applications continue to be developed in an ad hoc way, contributing to problems of usability, maintainability, quality and reliability. While Web development can benefit from established practices from other related disciplines, it has certain distinguishing characteristics that demand special considerations. In recent years, there have been developments towards addressing these considerations. Web engineering focuses on the methodologies, techniques, and tools that are the foundation of Web application development and which support their design, development, evolution, and evaluation. Web application development has certain characteristics that make it different from traditional software, information systems, or computer application development. Web engineering is multidisciplinary and encompasses contributions from diverse areas: systems analysis and design, software engineering, hypermedia/hypertext engineering, requirements engineering, human-computer interaction, user interface, data engineering, information science, information indexing and retrieval, testing, modelling and simulation, project management, and graphic design and presentation. Web engineering is neither a clone nor a subset of software engineering, although both involve programming and software development. While Web Engineering uses software engineering principles, it encompasses new approaches, methodologies, tools, techniques, and guidelines to meet the unique requirements of Web-based applications. == As a discipline == Proponents of Web engineering supported the establishment of Web engineering as a discipline at an early stage of Web. Major arguments for Web engineering as a new discipline are: Web-based Information Systems (WIS) development process is different and unique. Web engineering is multi-disciplinary; no single discipline (such as software engineering) can provide a complete theory basis, body of knowledge and practices to guide WIS development. Issues of evolution and lifecycle management when compared to more 'traditional' applications. Web-based information systems and applications are pervasive and non-trivial. The prospect of Web as a platform will continue to grow and it is worth being treated specifically. However, it has been controversial, especially for people in other traditional disciplines such as software engineering, to recognize Web engineering as a new field. The issue is how different and independent Web engineering is, compared with other disciplines. Main topics of Web engineering include, but are not limited to, the following areas: === Modeling disciplines === Business Processes for Applications on the Web Process Modelling of Web applications Requirements Engineering for Web applications B2B applications === Design disciplines, tools, and methods === UML and the Web Conceptual Modeling of Web Applications (aka. Web modeling) Prototyping Methods and Tools Web design methods CASE Tools for Web Applications Web Interface Design Data Models for Web Information Systems === Implementation disciplines === Integrated Web Application Development Environments Code Generation for Web Applications Software Factories for/on the Web Web 2.0, AJAX, E4X, ASP.NET, PHP and Other New Developments Web Services Development and Deployment === Testing disciplines === Testing and Evaluation of Web systems and Applications. Testing Automation, Methods, and Tools. === Applications categories disciplines === Semantic Web applications Document centric Web sites Transactional Web applications Interactive Web applications Workflow-based Web applications Collaborative Web applications Portal-oriented Web applications Ubiquitous and Mobile Web Applications Device Independent Web Delivery Localization and Internationalization of Web Applications Personalization of Web Applications == Attributes == === Web quality === Web Metrics, Cost Estimation, and Measurement Personalisation and Adaptation of Web applications Web Quality Usability of Web Applications Web accessibility Performance of Web-based applications === Content-related === Web Content Management Content Management System (CMS) Multimedia Authoring Tools and Software Authoring of adaptive hypermedia == Education == Master of Science: Web Engineering as a branch of study within the MSc program Web Sciences at the Johannes Kepler University Linz, Austria Diploma in Web Engineering: Web Engineering as a study program at the International Webmasters College (iWMC), Germany
Optical recording
The history of optical recording can be divided into a few number of distinct major contributions. The pioneers of optical recording worked mostly independently, and their solutions to the many technical challenges have very distinctive features, such as reflective disc (Compaan and Kramer) transparent disc (Gregg) floppy disc (Russell) rigid disc (Compaan and Kramer) focused laser beam for read-out through transparent substrate (Compaan and Kramer). == Gregg 1958 == Laserdisc technology, using a transparent disc, was invented by David Paul Gregg in 1958 (and patented in 1970 and 1990). By 1969 Philips had developed a videodisc in reflective mode, which has great advantages over the transparent mode. MCA and Philips decided to join their efforts. They first publicly demonstrated the videodisc in 1972. Laserdisc was first available on the market, in Atlanta, on December 15, 1978, two years after the VHS VCR and four years before the CD, which is based on Laserdisc technology. Philips produced the players and MCA produced the discs. The Philips/MCA cooperation was not successful, and discontinued after a few years. Several of the scientists responsible for the early research (John Winslow, Richard Wilkinson and Ray Dakin) founded Optical Disc Corporation (now ODC Nimbus). == Russell 1965 == While working at Pacific Northwest National Laboratory, James Russell invented an optical storage system for digital audio and video, patenting the concept in 1970. The earliest patents by Russell, US 3,501,586, and 3,795,902 were filed in 1966, and 1969. respectively. He built prototypes, and the first was operating in 1973. Russell had found a way to record digital information onto a photosensitive plate in tiny dark spots, each spot one micrometre from centre to centre, with a laser that wrote the binary patterns. Russell's first optical disc was distinctly different from the eventual compact disc product: the disc in the player was not read by laser light. A key characteristic of Russell's invention is that a laser is not used for the reading the disc, instead the entire disc or oblong sheet to be read is illuminated by a large playback light source at the back of the transparent foil. As a result, the information density is relatively low. By 1985, Russell held over 25 patents to various technologies related to optical recording and playback. Russell's intellectual property was purchased by Optical Recording Corporation (ORC) in Toronto in 1985, and this firm notified a number of CD manufacturers that their CD technology was based on patents held by ORC. In 1987, ORC signed an agreement with Sony whereby Sony paid for licensing of the technology. Further licenses followed from Philips and others. Warner Communications did not sign, and was sued by ORC. In 1992, the large CD manufacturer, now called Time Warner, was ordered to pay ORC US$30 million in patent violations. In the 1970 patent, the spot diameter was around 10 micrometres. Thus, the areal information density was around a factor hundred less than that of the CD as later developed. Russell continued to refine the concept throughout the 1970s. Philips and Sony, however, were able to put far greater resources into the parallel development of the concept, arriving at a smaller and more sophisticated product in just a few years. Russell's various partners and ventures failed to produce a single consumer product. == Korpel 1968 == Adrianus Korpel worked for the Zenith Electronics Corporation, when he developed very early optical videodisc systems, including holographic storage. == Kramer and Compaan 1969 == The Philips development of the videodisc technology began in 1969 with efforts by Dutch physicists Klaas Compaan and Piet Kramer to record video images in holographic form on disc. Their prototype Laserdisc shown in 1972 used a laser beam in reflective mode to read a track of pits using an FM video signal. Together with MCA, Philips brought the optical videodisk to market in 1978. The cooperation between Philips and MCA did not last long, and discontinued after a few years. == Immink and Doi 1979 == The Compact Disc (CD), which is based on MCA/Philips Laserdisc technology, was developed by a taskforce of Sony and Philips in 1979–1980. Toshi Doi and Kees Schouhamer Immink created the digital technologies that turned the analog Laserdisc into a high-density low-cost digital audio disc. The CD, available on the market since October 1982, remains the standard physical medium for sale of commercial audio recordings Standard CDs have a diameter of 120 mm and can hold up to 80 minutes of audio (700 MB of data). The Mini CD has various diameters ranging from 60 to 80 mm; they are sometimes used for CD singles or device drivers, storing up to 24 minutes of audio. The technology was later adapted and expanded to include data storage CD-ROM, write-once audio and data storage CD-R, rewritable media CD-RW, Super Audio CD (SACD), Video Compact Discs (VCD), Super Video Compact Discs (SVCD), PhotoCD, PictureCD, CD-i, and Enhanced CD. CD-ROMs and CD-Rs remain widely used technologies in the computer industry. The CD and its extensions have been extremely successful: in 2004, worldwide sales of CD audio, CD-ROM, and CD-R reached about 30 billion discs. By 2007, 200 billion CDs had been sold worldwide.
Push technology
Push technology, also known as server push, is a communication method where the communication is initiated by a server rather than a client. This approach is different from the "pull" method where the communication is initiated by a client. In push technology, clients can express their preferences for certain types of information or data, typically through a process known as the publish–subscribe model. In this model, a client "subscribes" to specific information channels hosted by a server. When new content becomes available on these channels, the server automatically sends, or "pushes," this information to the subscribed client. Under certain conditions, such as restrictive security policies that block incoming HTTP requests, push technology is sometimes simulated using a technique called polling. In these cases, the client periodically checks with the server to see if new information is available, rather than receiving automatic updates. == General use == Synchronous conferencing and instant messaging are examples of push services. Chat messages and sometimes files are pushed to the user as soon as they are received by the messaging service. Both decentralized peer-to-peer programs (such as WASTE) and centralized programs (such as IRC or XMPP) allow pushing files, which means the sender initiates the data transfer rather than the recipient. Email may also be a push system: SMTP is a push protocol (see Push e-mail). However, the last step—from mail server to desktop computer—typically uses a pull protocol like POP3 or IMAP. Modern e-mail clients make this step seem instantaneous by repeatedly polling the mail server, frequently checking it for new mail. The IMAP protocol includes the IDLE command, which allows the server to tell the client when new messages arrive. The original BlackBerry was the first popular example of push-email in a wireless context. Another example is the PointCast Network, which was widely covered in the 1990s. It delivered news and stock market data as a screensaver. Both Netscape and Microsoft integrated push technology through the Channel Definition Format (CDF) into their software at the height of the browser wars, but it was never very popular. CDF faded away and was removed from the browsers of the time, replaced in the 2000s with RSS (a pull system.) Other uses of push-enabled web applications include software updates distribution ("push updates"), market data distribution (stock tickers), online chat/messaging systems (webchat), auctions, online betting and gaming, sport results, monitoring consoles, and sensor network monitoring. == Examples == === Web push === The Web push proposal of the Internet Engineering Task Force is a simple protocol using HTTP version 2 to deliver real-time events, such as incoming calls or messages, which can be delivered (or "pushed") in a timely fashion. The protocol consolidates all real-time events into a single session which ensures more efficient use of network and radio resources. A single service consolidates all events, distributing those events to applications as they arrive. This requires just one session, avoiding duplicated overhead costs. Web Notifications are part of the W3C standard and define an API for end-user notifications. A notification allows alerting the user of an event, such as the delivery of an email, outside the context of a web page. As part of this standard, Push API is fully implemented in Chrome, Firefox, and Edge, and partially implemented in Safari as of February 2023. === HTTP server push === HTTP server push (also known as HTTP streaming) is a mechanism for sending unsolicited (asynchronous) data from a web server to a web browser. HTTP server push can be achieved through any of several mechanisms. As a part of HTML5 the Web Socket API allows a web server and client to communicate over a full-duplex TCP connection. Generally, the web server does not terminate a connection after response data has been served to a client. The web server leaves the connection open so that if an event occurs (for example, a change in internal data which needs to be reported to one or multiple clients), it can be sent out immediately; otherwise, the event would have to be queued until the client's next request is received. Most web servers offer this functionality via CGI (e.g., Non-Parsed Headers scripts on Apache HTTP Server). The underlying mechanism for this approach is chunked transfer encoding. Another mechanism is related to a special MIME type called multipart/x-mixed-replace, which was introduced by Netscape in 1995. Web browsers interpret this as a document that changes whenever the server pushes a new version to the client. It is still supported by Firefox, Opera, and Safari today, but it is ignored by Internet Explorer and is only partially supported by Chrome. It can be applied to HTML documents, and also for streaming images in webcam applications. The WHATWG Web Applications 1.0 proposal includes a mechanism to push content to the client. On September 1, 2006, the Opera web browser implemented this new experimental system in a feature called "Server-Sent Events". It is now part of the HTML5 standard. === Pushlet === In this technique, the server takes advantage of persistent HTTP connections, leaving the response perpetually "open" (i.e., the server never terminates the response), effectively fooling the browser to remain in "loading" mode after the initial page load could be considered complete. The server then periodically sends snippets of JavaScript to update the content of the page, thereby achieving push capability. By using this technique, the client doesn't need Java applets or other plug-ins in order to keep an open connection to the server; the client is automatically notified about new events, pushed by the server. One serious drawback to this method, however, is the lack of control the server has over the browser timing out; a page refresh is always necessary if a timeout occurs on the browser end. === Long polling === Long polling is itself not a true push; long polling is a variation of the traditional polling technique, but it allows emulating a push mechanism under circumstances where a real push is not possible, such as sites with security policies that require rejection of incoming HTTP requests. With long polling, the client requests to get more information from the server exactly as in normal polling, but with the expectation that the server may not respond immediately. If the server has no new information for the client when the poll is received, then instead of sending an empty response, the server holds the request open and waits for response information to become available. Once it does have new information, the server immediately sends an HTTP response to the client, completing the open HTTP request. Upon receipt of the server response, the client often immediately issues another server request. In this way the usual response latency (the time between when the information first becomes available and the next client request) otherwise associated with polling clients is eliminated. For example, BOSH is a popular, long-lived HTTP technique used as a long-polling alternative to a continuous TCP connection when such a connection is difficult or impossible to employ directly (e.g., in a web browser); it is also an underlying technology in the XMPP, which Apple uses for its iCloud push support. === Flash XML Socket relays === This technique, used by chat applications, makes use of the XML Socket object in a single-pixel Adobe Flash movie. Under the control of JavaScript, the client establishes a TCP connection to a unidirectional relay on the server. The relay server does not read anything from this socket; instead, it immediately sends the client a unique identifier. Next, the client makes an HTTP request to the web server, including this identifier with it. The web application can then push messages addressed to the client to a local interface of the relay server, which relays them over the Flash socket. The advantage of this approach is that it appreciates the natural read-write asymmetry that is typical of many web applications, including chat, and as a consequence it offers high efficiency. Since it does not accept data on outgoing sockets, the relay server does not need to poll outgoing TCP connections at all, making it possible to hold open tens of thousands of concurrent connections. In this model, the limit to scale is the TCP stack of the underlying server operating system. === Reliable Group Data Delivery (RGDD) === In services such as cloud computing, to increase reliability and availability of data, it is usually pushed (replicated) to several machines. For example, the Hadoop Distributed File System (HDFS) makes 2 extra copies of any object stored. RGDD focuses on efficiently casting an object from one location to many while saving bandwidth by sending minimal number of copies (only one in the best case) of
Shaded Picture System
The Shaded Picture System was a 3D raster computer display processor introduced by Evans & Sutherland in October 1973. The Shaded Picture System was the first general-purpose, commercially available raster computer graphics display processor capable of real-time, shaded 3D graphics. It could only display black and white graphics at a resolution of 256 by 256. It was extremely expensive, and very few units were ever sold. == History == The principles of shaded, hidden-line true 3D graphics were pioneered at the University of Utah in 1967. However, this algorithm was slow and would take several minutes to produce an image. In 1970, Gary Watkins developed a FORTRAN simulator of a faster algorithm that would theoretically generate shaded 3D images in real-time, "if implemented in suitable hardware". The simulator itself was still not capable of real-time shaded 3D image rendering. Evans & Sutherland developed a functional prototype of this "suitable hardware", which was later sold as the Shaded Picture System in 1973. About a year earlier in 1972, Evans & Sutherland sold the first and only CT1 to Case Western Reserve University. The CT1, or Continuous Tone 1, was a specialized image generator, not meant as a marketable or mass-produced product. At the time, the CT1, along with G.E./NASA's upgraded Electronic Scene Generator from 1971, would have been the only real-time raster graphics systems sold to customers comparable to the Shaded Picture System, although both the CT1 and Electronic Scene Generator were intentionally produced as one-off products and specialized for the needs of their customers. The Shaded Picture System, in contrast, was intentionally marketed.In early 1975, Evans & Sutherland demonstrated a random-access video frame buffer using relatively low-cost semiconductor memory, which was much more capable than the Shaded Picture System. When interfaced with a (non-shaded) E&S Picture System, the frame buffer had a resolution of 512 by 512 in grayscale and partial color capabilities. By the end of 1975, this frame buffer was commercially available.
DBOS
DBOS (Formerly Database-Oriented Operating System, now just DBOS) is an open source durable workflow execution software library written for the Python, TypeScript, Java, and Go programming languages. DBOS arose from a joint open source project from MIT and Stanford, after a discussion between Michael Stonebraker and Matei Zaharia on how to scale and improve scheduling and performance of millions of Apache Spark tasks. Today it is a commercial company that offers an open source system to add durable computing to any software, built on concepts derived from the joint research project. == History == === 2020: Academic R&D Project === DBOS originated in 2020 as a joint open source project between MIT, Stanford, and Carnegie Mellon. The project explored the idea of operating system services built atop a distributed database - a database-oriented operating system meant to simplify and improve the scalability, security and resilience of large-scale distributed applications. The basic concept was to run a multi-node multi-core, transactional, highly-available distributed database, such as VoltDB, as the only application for a microkernel, and then to implement scheduling, messaging, file systems and other operating system services on top of the database. The architectural philosophy is described by this quote from the abstract of their initial preprint: All operating system state should be represented uniformly as database tables, and operations on this state should be made via queries from otherwise stateless tasks. This design makes it easy to scale and evolve the OS without whole-system refactoring, inspect and debug system state, upgrade components without downtime, manage decisions using machine learning, and implement sophisticated security features. A prototype was built with competitive performance to existing systems. ==