Alexandra Sasha Luccioni (née Vorobyova; born 1990) is a computer scientist specializing in the intersection of artificial intelligence (AI) and climate change. Her work focuses on quantifying the environmental impact of AI technologies and promoting sustainable practices in machine learning development. == Early life and education == Alexandra Sasha Vorobyova was born in the Ukrainian Soviet Socialist Republic in 1990. When she was four years old, her family relocated to Ontario, Canada. Her interest in science is influenced by her family's history; her mother, grandmother, and great-grandmother all pursued careers in scientific fields. Luccioni earned a B.A. in language science from University of Paris III: Sorbonne Nouvelle in 2010. Subsequently, she completed a M.S. in cognitive science, with a minor in natural language processing, at École normale supérieure in Paris in 2012. Luccioni obtained her PhD in cognitive computing from Université du Québec à Montréal (UQAM) in 2018. == Career == Luccioni began her professional career at Nuance Communications in 2017, where she focused on natural language processing (NLP) and machine learning (ML) techniques to enhance conversational agents. She then joined Morgan Stanley’s AI/ML Center of Excellence in 2018, working on explainable artificial intelligence (AI) and decision-making systems. In 2019, she became a postdoctoral researcher at Université de Montréal and Mila, collaborating with computer scientist Yoshua Bengio on a project titled This Climate Does Not Exist. This initiative used generative adversarial networks to visualize the effects of climate change. During this time, she also contributed to integrating fairness and accountability into machine learning education at Mila. Luccioni briefly worked with the United Nations Global Pulse in 2021, developing tools to monitor COVID-19 misinformation. Later that year, she joined Hugging Face as a research scientist. Her role includes quantifying the carbon footprint of AI systems, co-chairing the carbon working group in the Big Science project, and advancing responsible machine learning practices. She helped create "CodeCarbon," an open-source software tool that estimates the carbon emissions produced during the training and operation of machine learning models. In addition to her research, she has developed tools to measure the environmental impact of AI models, communicated findings through media engagements, and presented at international conferences, including a TED Talk. In 2024, she was listed on BBC 100 Women and Time 100 AI.
Web application firewall
A Web application firewall (WAF) is a specific form of application firewall that filters, monitors, and blocks HTTP traffic to and from a web service. By inspecting HTTP traffic, it can prevent attacks exploiting a Web application's known vulnerabilities, such as SQL injection, cross-site scripting (XSS), file inclusion, and improper system configuration. Financial institutions often utilize WAFs to help in the mitigation of Web application zero-day vulnerabilities, as well as hard-to-patch bugs or weaknesses through custom attack signature strings. == History == Dedicated Web application firewalls entered the market in the late 1990s during a time when web server attacks were becoming more prevalent. Early WAF products, from Kavado and Gilian technologies, tried to solve the increasing amount of attacks on Web applications in the late 1990s. In 2002, the open-source project ModSecurity was formed in order to make WAF technology more accessible. They finalized a core rule set for protecting Web applications, based on OASIS Web Application Security Technical Committee’s (WAS TC) vulnerability work. In 2003, they expanded and standardized rules through the Open Web Application Security Project’s (OWASP) Top 10 List, an annual ranking for Web security vulnerabilities. This list would become the industry standard for Web application security compliance. Since then, the market has continued to grow and evolve, especially focusing on credit card fraud prevention. With the development of the Payment Card Industry Data Security Standard (PCI DSS), a standardization of control over cardholder data, security has become more regulated in this sector. == Description == A Web application firewall is a special type of application firewall that applies specifically to Web applications. It is deployed in front of Web applications and analyzes bi-directional web-based (HTTP) traffic – detecting and blocking anything malicious. The OWASP provides a broad technical definition for a WAF as “a security solution on the Web application level which – from a technical point of view – does not depend on the application itself”. According to the PCI DSS Information Supplement for requirement 6.6, a WAF is defined as “a security policy enforcement point positioned between a Web application and the client endpoint. This functionality can be implemented in software or hardware, running in an appliance device, or in a typical server running a common operating system. It may be a stand-alone device or integrated into other network components.” In other words, a WAF can be a virtual or physical appliance that prevents vulnerabilities in Web applications from being exploited by outside threats. These vulnerabilities may be because the application itself is a legacy type or was insufficiently coded by design. The WAF addresses these code shortcomings by special configurations of rule-sets, also known as policies. Previously unknown vulnerabilities can be discovered through penetration testing or via a vulnerability scanner. A Web application vulnerability scanner, also known as a web application security scanner, is defined in the SAMATE NIST 500-269 as “an automated program that examines Web applications for potential security vulnerabilities. In addition to searching for Web application-specific vulnerabilities, the tools also look for software coding errors.” Resolving vulnerabilities is commonly referred to as remediation. Corrections to the code can be made in the application, but typically a more prompt response is necessary. In these situations, the application of a custom policy for a unique Web application vulnerability to provide a temporary but immediate fix (known as a virtual patch) may be necessary. WAFs are not an ultimate security solution, rather they are meant to be used in conjunction with other network perimeter security solutions such as network firewalls and intrusion prevention systems to provide a holistic defense strategy. WAFs typically follow a positive security model, a negative security, or a combination of both as mentioned by the SANS Institute. WAFs use a combination of rule-based logic, parsing, and signatures to detect and prevent attacks such as cross-site scripting and SQL injection. In general, features like browser emulation, obfuscation and virtualization, and IP obfuscation are used to attempt to bypass WAFs. The OWASP produces a list of the top ten Web application security flaws. All commercial WAF offerings cover these ten flaws at a minimum. There are non-commercial options as well. As mentioned earlier, the well-known open-source WAF engine called ModSecurity is one of these options. A WAF engine alone is insufficient to provide adequate protection, therefore OWASP along with Trustwave's Spiderlabs help organize and maintain a Core-Rule Set via GitHub to use with the ModSecurity WAF engine. == Deployment options == Although the names for operating mode may differ, WAFs are basically deployed inline in three different ways. According to NSS Labs, deployment options are transparent bridge, transparent reverse proxy, and reverse proxy. "Transparent" refers to the fact that the HTTP traffic is sent straight to the Web application, therefore the WAF is transparent between the client and server. This is in contrast to reverse proxy, where the WAF acts as a proxy, and the client’s traffic is sent directly to the WAF. The WAF then separately sends filtered traffic to Web applications. This can provide additional benefits such as IP masking but may introduce disadvantages such as performance latencies. == JA3 fingerprint == JA3, developed by Salesforce in 2017, is a technique for generating a unique fingerprint for SSL/TLS traffic based on specific fields in the handshake, such as the version, cipher suites, and extensions used by the client. This fingerprint enables the identification and tracking of clients based on the characteristics of their encrypted traffic. In the context of distributed denial of service (DDoS) protection, JA3 fingerprints are used to detect and differentiate malicious traffic, often associated with attack bots, from legitimate traffic, allowing for more precise filtering of potential threats. In September 2023, AWS WAF announced built-in support for JA3, enabling customers to inspect the JA3 fingerprints of incoming requests. JA3 was deprecated in May 2025 in favor of JA4. JA4 is currently patent pending.
Fediverse
The Fediverse (commonly shortened to fedi) is a collection of social networking services that can communicate with each other (formally known as federation) using a common protocol. Users of different websites can send and receive status updates, multimedia files and other data across the network. The term Fediverse is a portmanteau of federation and universe. The majority of Fediverse platforms are based on free and open-source software, and create connections between servers using the ActivityPub protocol. Some software still supports older federation protocols as well, such as OStatus, the Diaspora protocol and Zot, while newer protocols such as AT Protocol connect via network bridges. Diaspora is the only actively developed software project classified under the original definition of Fediverse that does not support ActivityPub. == Design == While a traditional social networking service will host all its content on servers managed by the owner of the website, the decentralized structure of the Fediverse allows any individual or organization to host a social platform using their own servers (referred to as an "instance"). Every instance is independent, and can set its own rules and expectations. Even so, much like how users of one email service such as Gmail can still send emails to users of another service such as Outlook, users may still view content and interact with users on any other instance in the Fediverse. A user on one Mastodon instance, for example, may view and interact with posts made by a user on a different instance even if it is not running Mastodon. Instances hosted by different social networking services may also communicate with one another. A user on the microblogging platform Misskey, for example, may view and interact with posts made by users on Mastodon. Some Fediverse networks even allow users to interact with different social networking formats from the same platform. For example, a user on a social news instance running Lemmy can interact with another post from an mbin instance, a similar service, as well as microblog statuses from Mastodon. === Content moderation and user safety === Decentralized social networking platforms introduce new challenges and difficulties for user trust and safety. By nature of the Fediverse, operators of an instance are solely responsible for moderation of its content. As there is no form of centralized governance or moderation across the Fediverse, it is impossible for an instance to be "removed" from the Fediverse; it can only be defederated per an instance operator's choice, which makes that instance's content inaccessible from the operator's instance. Individual instances are responsible for defining their own content policies, which may then be enforced by its staff. Moderation of a Fediverse instance differs significantly from that of traditional social media platforms, as moderators are responsible not only for content posted by users of that instance ("local users"), but also for content posted by users of other instances ("remote users"). == History == === Historical protocols === The concept and the functionality of the Fediverse existed before the ActivityPub protocol and the term itself. One of the first projects that included support for a decentralized social networking service was Laconica, a microblogging platform which implemented the OpenMicroBlogging protocol for communicating between different installations of the software. The software was later renamed to StatusNet in 2009, before being merged into the GNU social project in 2013 along with Free Social, with the two latter servers being a fork of StatusNet. Over time, the limitations of the OpenMicroBlogging protocol became more apparent, being designed as a one-way text messaging system. To replace the ageing protocol, OStatus was devised as an open standard for microblogging, combining various other technologies like Salmon, Atom, WebSub and ActivityStreams into a single protocol used for communicating between instances. StatusNet first implemented the OStatus protocol on March 3, 2010, with version 0.9.0, and OStatus quickly became the most popular federated protocol in usage. Around the same time as OStatus was gaining popularity, the Diaspora social network was formed, using its own federated protocol. To illustrate the differences between the two protocols, the terms of the Fediverse and the federation began to enter common usage, mainly after 2017. The term "the Fediverse" was used to describe the network formed by software using the OStatus protocol, such as GNU Social, Mastodon, and Friendica, in contrast to the competing diaspora protocol under "the federation". === ActivityPub === In December 2012, the flagship StatusNet instance at the time, identi.ca, transitioned away to a new software named pump.io, with a new federation protocol to replace OStatus. The new protocol was designed to be useful for general activity streams and not just status updates, and replaced many of OStatus' external dependencies with JSON-LD and a REST API for its messaging and inbox systems, as well as making more use of ActivityStreams. While not as utilized as its OStatus predecessor, it would later become influential in the development of the ActivityPub standard. In January 2018, the W3C presented the ActivityPub protocol as a recommended standard. The standard aimed to improve the interoperability between different software packages running on a wide network of servers and to supersede both the OStatus protocol and Pump.io. By 2019, almost all software that was using OStatus had added support for ActivityPub. While Mastodon began to remove OStatus support, other projects maintained it in their code, such as Friendica (which also maintained diaspora support along with ActivityPub). === AT Protocol === A major protocol often contrasted with ActivityPub is the AT Protocol, which powers the Bluesky social network. While both protocols aim to create decentralized social networks, they employ different technical philosophies regarding user identity. Developers of the AT Protocol, including Bluesky CEO Jay Graber, have stated they chose not to use ActivityPub because it did not natively support easy "account portability", the ability for a user to move their account, data, and social graph to a new provider without relying on the original server to authorize the move. In the ActivityPub model (used by Mastodon), a user's identity is typically tied to a specific server, similar to an email address; if that server goes offline, the identity can be lost. The AT Protocol aims to solve this by separating identity from hosting, allowing users to switch providers without losing their identity. Although the two protocols are technically incompatible by default, third-party "bridges" such as Bridgy Fed have been developed to allow users on ActivityPub networks to follow and interact with users on the AT Protocol network, and vice versa. === Other Fediverse protocols === While the Fediverse has traditionally been the network most commonly referred to and used as an example regarding the subject of decentralized social networks, alternatives to it and the accompanying ActivityPub have been developed and deployed. Smaller competitors such as Nostr and Farcaster have become popular within the cryptocurrency community. These protocols have used ActivityPub as a frame of reference for which to design their own architecture, as these newer protocols use a different federation model based on publishing content to relays for distribution rather than ActivityPub's server-centric model. Despite their differences, software exists that permit the bridging of user content between these protocols, including "double-bridges" that span multiple protocols for the purpose of distributing the same content. == Adoption == Users have been slow to embrace the Fediverse due to poor user experience and excessive complexity. Following the acquisition of Twitter by Elon Musk in November 2022, certain major social networks, including Threads, Tumblr and Flipboard, expressed interest in supporting the ActivityPub protocol, as a large number of users began to migrate to Mastodon, a server that supports the Fediverse and was also the most popular alternative to Twitter at the time. Flickr also expressed support in supporting ActivityPub. As of November 2022, no information had been released by Flickr after the initial tweets by the CEO, with support for ActivityPub suspected to be on hold or cancelled. In 2024, the local government of the Stary Sącz municipality in Poland launched their own PeerTube instance in order to de facto abolish its presence on YouTube. According to the government, they stopped using YouTube for official communications "in order to adhere to the appropriate regulations". In the same year, VIVERSE, HTC Vive's metaverse platform, implemented support for ActivityPub in their chat feature, allowing users to send direct messages to other
Digital signal
A digital signal is a signal that represents data as a sequence of discrete values; at any given time it can only take on, at most, one of a finite number of values. This contrasts with an analog signal, which represents continuous values; at any given time it represents a real number within an infinite set of values. Simple digital signals represent information in discrete bands of levels. All levels within a band of values represent the same information state. In most digital circuits, the signal can have two possible valid values; this is called a binary signal or logic signal. They are represented by two voltage bands: one near a reference value (typically termed as ground or zero volts), and the other a value near the supply voltage. These correspond to the two values zero and one (or false and true) of the Boolean domain, so at any given time a binary signal represents one binary digit (bit). Because of this discretization, relatively small changes to the signal levels do not leave the discrete envelope, and as a result are ignored by signal state sensing circuitry. As a result, digital signals have noise immunity; electronic noise, provided it is not too great, will not affect digital circuits, whereas noise always degrades the operation of analog signals to some degree. Digital signals having more than two states are occasionally used; circuitry using such signals is called multivalued logic. For example, signals that can assume three possible states are called three-valued logic. In a digital signal, the physical quantity representing the information may be a variable electric current or voltage, the intensity, phase or polarization of an optical or other electromagnetic field, acoustic pressure, the magnetization of a magnetic storage media, etcetera. Digital signals are used in all digital electronics, notably computing equipment and data transmission. == Definitions == The term digital signal has related definitions in different contexts. === In digital electronics === In digital electronics, a digital signal is a pulse amplitude modulated signal, i.e., a sequence of fixed-width electrical pulses or light pulses, each occupying one of a discrete number of levels of amplitude. A special case is a logic signal or a binary signal, which varies between a low and a high signal level. The pulse trains in digital circuits are typically generated by metal–oxide–semiconductor field-effect transistor (MOSFET) devices, due to their rapid on–off electronic switching speed and large-scale integration (LSI) capability. In contrast, bipolar junction transistors more slowly generate signals resembling sine waves. === In signal processing === In digital signal processing, a digital signal is a representation of a physical signal that is sampled and quantized. A digital signal is an abstraction that is discrete in time and amplitude. The signal's value only exists at regular time intervals, since only the values of the corresponding physical signal at those sampled moments are significant for further digital processing. The digital signal is a sequence of codes drawn from a finite set of values. The digital signal may be stored, processed or transmitted physically as a pulse-code modulation (PCM) signal. === In communications === In digital communications, a digital signal is a continuous-time physical signal, alternating between a discrete number of waveforms, representing a bitstream. The shape of the waveform depends on the transmission scheme, which may be either a line coding scheme allowing baseband transmission; or a digital modulation scheme, allowing passband transmission over long wires or over a limited radio frequency band. Such a carrier-modulated sine wave is considered a digital signal in literature on digital communications and data transmission, but considered as a bit stream converted to an analog signal in specific cases where the signal will be carried over a system meant for analog communication, such as an analog telephone line. In communications, sources of interference are usually present, and noise is frequently a significant problem. The effects of interference are typically minimized by filtering off interfering signals as much as possible and by using data redundancy. The main advantages of digital signals for communications are often considered to be noise immunity, and the ability, in many cases such as with audio and video data, to use data compression to greatly decrease the bandwidth that is required on the communication media. == Logic voltage levels == A waveform that switches representing the two states of a Boolean value (0 and 1, or low and high, or false and true) is referred to as a digital signal or logic signal or binary signal when it is interpreted in terms of only two possible digits. The two states are usually represented by some measurement of an electrical property: Voltage is the most common, but current is used in some logic families. Two ranges of voltages are typically defined for each logic family, which are frequently not directly adjacent. The signal is low when in the low range and high when in the high range, and in between the two ranges the behavior can vary between different types of gates. The clock signal is a special digital signal that is used to synchronize many digital circuits. The image shown can be considered the waveform of a clock signal. Logic changes are triggered either by the rising edge or the falling edge. The rising edge is the transition from a low voltage (level 1 in the diagram) to a high voltage (level 2). The falling edge is the transition from a high voltage to a low one. Although in a highly simplified and idealized model of a digital circuit, we may wish for these transitions to occur instantaneously, no real-world circuit is purely resistive, and therefore no circuit can instantly change voltage levels. This means that during a short, finite transition time, the output may not properly reflect the input, and will not correspond to either a logically high or low voltage. == Modulation == To create a digital signal, a signal must be modulated with a control signal to produce it. The simplest modulation, a type of unipolar encoding, is simply to switch on and off a DC signal so that high voltages represent a '1' and low voltages are '0'. In digital radio schemes, one or more carrier waves are amplitude, frequency or phase modulated by the control signal to produce a digital signal suitable for transmission. Asymmetric Digital Subscriber Line (ADSL) over telephone wires, does not primarily use binary logic; the digital signals for individual carriers are modulated with different-valued logics, depending on the Shannon capacity of the individual channel. == Clocking == Digital signals may be sampled by a clock signal at regular intervals by passing the signal through a flip-flop. When this is done, the input is measured at the clock edge and the signal from that time. The signal is then held steady until the next clock. This process is the basis of synchronous logic. Asynchronous logic also exists, which uses no single clock, and generally operates more quickly, and may use less power, but is significantly harder to design.
WebCL
WebCL (Web Computing Language) is a JavaScript binding to OpenCL for heterogeneous parallel computing within any compatible web browser without the use of plug-ins, first announced in March 2011. It is developed on similar grounds as OpenCL and is considered as a browser version of the latter. Primarily, WebCL allows web applications to actualize speed with multi-core CPUs and GPUs. With the growing popularity of applications that need parallel processing like image editing, augmented reality applications and sophisticated gaming, it has become more important to improve the computational speed. With these background reasons, a non-profit Khronos Group designed and developed WebCL, which is a Javascript binding to OpenCL with a portable kernel programming, enabling parallel computing on web browsers, across a wide range of devices. In short, WebCL consists of two parts, one being Kernel programming, which runs on the processors (devices) and the other being JavaScript, which binds the web application to OpenCL. The completed and ratified specification for WebCL 1.0 was released on March 19, 2014. == Implementation == Currently, no browsers natively support WebCL. However, non-native add-ons are used to implement WebCL. For example, Nokia developed a WebCL extension. Mozilla does not plan to implement WebCL in favor of WebGL Compute Shaders, which were in turn scrapped in favor of WebGPU. Mozilla (Firefox) - hg.mozilla.org/projects/webcl/ === WebCL working draft === Samsung (WebKit) - github.com/SRA-SiliconValley/webkit-webcl (unavailable) Nokia (Firefox) - github.com/toaarnio/webcl-firefox (down since Nov 2014, Last Version for FF 34) Intel (Crosswalk) - www.crosswalk-project.org === Example C code === The basic unit of a parallel program is kernel. A kernel is any parallelizable task used to perform a specific job. More often functions can be realized as kernels. A program can be composed of one or more kernels. In order to realize a kernel, it is essential that a task is parallelizable. Data dependencies and order of execution play a vital role in producing efficient parallelized algorithms. A simple example can be thought of the case of loop unrolling performed by C compilers, where a statement like:can be unrolled into:Above statements can be parallelized and can be made to run simultaneously. A kernel follows a similar approach where only the snapshot of the ith iteration is captured inside kernel. Rewriting the above code using a kernel:Running a WebCL application involves the following steps: Allow access to devices and provide context Hand over the kernel to a device Cause the device to execute the kernel Retrieve results from the device Use the data inside JavaScript Further details about the same can be found at == Exceptions List == WebCL, being a JavaScript based implementation, doesn't return an error code when errors occur. Instead, it throws an exception such as OUT_OF_RESOURCES, OUT_OF_HOST_MEMORY, or the WebCL-specific WEBCL_IMPLEMENTATION_FAILURE. The exception object describes the machine-readable name and human-readable message describing the error. The syntax is as follows: From the code above, it can be observed that the message field can be a NULL value. Other exceptions include: INVALID_OPERATION – if the blocking form of this function is called from a WebCLCallback INVALID_VALUE – if eventWaitList is empty INVALID_CONTEXT – if events specified in eventWaitList do not belong to the same context INVALID_DEVICE_TYPE – if deviceType is given, but is not one of the valid enumerated values DEVICE_NOT_FOUND – if there is no WebCLDevice available that matches the given deviceType More information on exceptions can be found in the specs document. There is another exception that is raised upon trying to call an object that is ‘released’. On using the release method, the object doesn't get deleted permanently but it frees the resources associated with that object. In order to avoid this exception, releaseAll method can be used, which not only frees the resources but also deletes all the associated objects created. == Security == WebCL, being an open-ended software developed for web applications, has lots of scope for vulnerabilities in the design and development fields too. This forced the developers working on WebCL to give security the utmost importance. Few concerns that were addressed are: Out-of-bounds Memory Access: This occurs by accessing the memory locations, outside the allocated space. An attacker can rewrite or erase all the important data stored in those memory locations. Whenever there arises such a case, an error must be generated at the compile time, and zero must be returned at run-time, not letting the program override the memory. A project WebCL Validator, was initiated by the Khronos Group (developers) on handling this vulnerability. Memory Initialization: This is done to prevent the applications to access the memory locations of previous applications. WebCL ensures that this doesn't happen by initializing all the buffers, variables used to zero before it runs the current application. OpenCL 1.2 has an extension ‘cl_khr_initialize_memory’, which enables this. Denial of Service: The most common attack on web applications cannot be eliminated by WebCL or the browser. OpenCL can be provided with watchdog timers and pre-emptive multitasking, which can be used by WebCL in order to detect and terminate the contexts that are taking too long or consume lot of resources. There is an extension of OpenCL 1.2 ‘cl_khr_terminate_context’ like for the previous one, which enables to terminate the process that might cause a denial of service attack. == Related browser bugs == Bug 664147 - [WebCL] add openCL in gecko, Mozilla Bug 115457: [Meta] WebCL support for WebKit, WebKit Bugzilla
Application permissions
Permissions are a means of controlling and regulating access to specific system- and device-level functions by software. Typically, types of permissions cover functions that may have privacy implications, such as the ability to access a device's hardware features (including the camera and microphone), and personal data (such as storage devices, contacts lists, and the user's present geographical location). Permissions are typically declared in an application's manifest, and certain permissions must be specifically granted at runtime by the user—who may revoke the permission at any time. Permission systems are common on mobile operating systems, where permissions needed by specific apps must be disclosed via the platform's app store. == Mobile devices == On mobile operating systems for smartphones and tablets, typical types of permissions regulate: Access to storage and personal information, such as contacts, calendar appointments, etc. Location tracking. Access to the device's internal camera and/or microphone. Access to biometric sensors, including fingerprint readers and other health sensors.. Internet access. Access to communications interfaces (including their hardware identifiers and signal strength where applicable, and requests to enable them), such as Bluetooth, Wi-Fi, NFC, and others. Making and receiving phone calls. Sending and reading text messages The ability to perform in-app purchases. The ability to "overlay" themselves within other apps. Installing, deleting and otherwise managing applications. Authentication tokens (e.g., OAuth tokens) from web services stored in system storage for sharing between apps. Prior to Android 6.0 "Marshmallow", permissions were automatically granted to apps at runtime, and they were presented upon installation in Google Play Store. Since Marshmallow, certain permissions now require the app to request permission at runtime by the user. These permissions may also be revoked at any time via Android's settings menu. Usage of permissions on Android are sometimes abused by app developers to gather personal information and deliver advertising; in particular, apps for using a phone's camera flash as a flashlight (which have grown largely redundant due to the integration of such functionality at the system level on later versions of Android) have been known to require a large array of unnecessary permissions beyond what is actually needed for the stated functionality. iOS imposes a similar requirement for permissions to be granted at runtime, with particular controls offered for enabling of Bluetooth, Wi-Fi, and location tracking. == WebPermissions == WebPermissions is a permission system for web browsers. When a web application needs some data behind permission, it must request it first. When it does it, a user sees a window asking him to make a choice. The choice is remembered, but can be cleared lately. Currently the following resources are controlled: geolocation desktop notifications service workers sensors audio capturing devices, like sound cards, and their model names and characteristics video capturing devices, like cameras, and their identifiers and characteristics == Analysis == The permission-based access control model assigns access privileges for certain data objects to application. This is a derivative of the discretionary access control model. The access permissions are usually granted in the context of a specific user on a specific device. Permissions are granted permanently with few automatic restrictions. In some cases permissions are implemented in 'all-or-nothing' approach: a user either has to grant all the required permissions to access the application or the user can not access the application. There is still a lack of transparency when the permission is used by a program or application to access the data protected by the permission access control mechanism. Even if a user can revoke a permission, the app can blackmail a user by refusing to operate, for example by just crashing or asking user to grant the permission again in order to access the application. The permission mechanism has been widely criticized by researchers for several reasons, including; Intransparency of personal data extraction and surveillance, including the creation of a false sense of security; End-user fatigue of micro-managing access permissions leading to a fatalistic acceptance of surveillance and intransparency; Massive data extraction and personal surveillance carried out once the permissions are granted. Some apps, such as XPrivacy and Mockdroid spoof data in order to act as a measure for privacy. Further transparency methods include longitudinal behavioural profiling and multiple-source privacy analysis of app data access.
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