Hancom Office is a proprietary office suite that includes a word processor, spreadsheet software, presentation software, and a PDF editor as well as their online versions accessible via a web browser. It is primarily addressed to Korean users. Hancom Office is written in Java and C++ that runs on Android, iOS, macOS and Windows platforms. == Products == Hangul - Hangul is a word processor developed by Hancom. It is a product that eliminates the inconvenience of the original Hangul word processor, which was limited to Hangul cards or PC models. Originally, the name was written using the '아래아' character, a vowel letter that is obsolete in modern Korean, and it was referred to as 'HWP' (an abbreviation for Hangul Word Processor), '아래아 한글' (Arae-a Hangul), '한/글' (Han/Geul), and so on. Hangul is currently the most widely used word processor in South Korea, often used alongside Microsoft Word. HanWord - word processor compatible with Word HanCell - spreadsheet program HanShow - presentation program Hancom Office Hanword Viewer - For viewing documents created by Hancom Office or Microsoft Office
Vulnerabilities Equities Process
The Vulnerabilities Equities Process (VEP) is a process used by the U.S. federal government to determine on a case-by-case basis how it should treat zero-day computer security vulnerabilities: whether to disclose them to the public to help improve general computer security, or to keep them secret for offensive use against the government's adversaries. The VEP was first developed during the period 2008–2009, but only became public in 2016, when the government released a redacted version of the VEP in response to a FOIA request by the Electronic Frontier Foundation. Following public pressure for greater transparency in the wake of the Shadow Brokers affair, the U.S. government made a more public disclosure of the VEP process in November 2017. == Participants == According to the VEP plan published in 2017, the Equities Review Board (ERB) is the primary forum for interagency deliberation and determinations concerning the VEP. The ERB meets monthly, but may also be convened sooner if an immediate need arises. The ERB consists of representatives from the following agencies: Office of Management and Budget Office of the Director of National Intelligence (including the Intelligence Community-Security Coordination Center) United States Department of the Treasury United States Department of State United States Department of Justice (including the Federal Bureau of Investigation and the National Cyber Investigative Joint Task Force) Department of Homeland Security (including the National Cybersecurity and Communications Integration Center and the United States Secret Service) United States Department of Energy United States Department of Defense (to include the National Security Agency, including Information Assurance and Signals Intelligence elements), United States Cyber Command, and DoD Cyber Crime Center) United States Department of Commerce Central Intelligence Agency The National Security Agency serves as the executive secretariat for the VEP. == Process == According to the November 2017 version of the VEP, the process is as follows: === Submission and notification === When an agency finds a vulnerability, it will notify the VEP secretariat as soon as is possible. The notification will include a description of the vulnerability and the vulnerable products or systems, together with the agency's recommendation to either disseminate or restrict the vulnerability information. The secretariat will then notify all participants of the submission within one business day, requesting them to respond if they have an relevant interest. === Equity and discussions === An agency expressing an interest must indicate whether it concurs with the original recommendation to disseminate or restrict within five business days. If it does not, it will hold discussions with the submitting agency and the VEP secretariat within seven business days to attempt to reach consensus. If no consensus is reached, the participants will suggest options for the Equities Review Board. === Determination to disseminate or restrict === Decisions whether to disclose or restrict a vulnerability should be made quickly, in full consultation with all concerned agencies, and in the overall best interest of the competing interests of the missions of the U.S. government. As far as possible, determinations should be based on rational, objective methodologies, taking into account factors such as prevalence, reliance, and severity. If the review board members cannot reach consensus, they will vote on a preliminary determination. If an agency with an equity disputes that decision, they may, by providing notice to the VEP secretariat, elect to contest the preliminary determination. If no agency contests a preliminary determination, it will be treated as a final decision. === Handling and follow-on actions === If vulnerability information is released, this will be done as quickly as possible, preferably within seven business days. Disclosure of vulnerabilities will be conducted according to guidelines agreed on by all members. The submitting agency is presumed to be most knowledgeable about the vulnerability and, as such, will be responsible for disseminating vulnerability information to the vendor. The submitting agency may elect to delegate dissemination responsibility to another agency on its behalf. The releasing agency will promptly provide a copy of the disclosed information to the VEP secretariat for record keeping. Additionally, the releasing agency is expected to follow up so the ERB can determine whether the vendor's action meets government requirements. If the vendor chooses not to address a vulnerability, or is not acting with urgency consistent with the risk of the vulnerability, the releasing agency will notify the secretariat, and the government may take other mitigation steps. == Criticism == The VEP process has been criticized for a number of deficiencies, including restriction by non-disclosure agreements, lack of risk ratings, special treatment for the NSA, and less than whole-hearted commitment to disclosure as the default option. == UK equivalent == British intelligence agencies—GCHQ in particular—follow a similar approach, also known as the Equities Process, to determine whether to disclose or retain security vulnerabilities. The Investigatory Powers Act 2016 was amended in 2022 to bring oversight of the operation of the process within the remit of the Investigatory Powers Commissioner. Details of the process were made public in 2018.
SAP NetWeaver Visual Composer
SAP NetWeaver Visual Composer is SAP’s web-based software modelling tool. It enables business process specialists and developers to create business application components, without coding. Visual Composer produces applications in a declarative form, enabling code-free execution mode for multiple runtime environments. It provides application lifecycle support by maintaining the connection between an application and its model throughout its lifecycle. Visual Composer is designed with an open architecture, which enables developers to extend its design-time environment and modelling language, as well as to integrate external data services. The tool aims to increase productivity by reducing development effort time, and narrowing the gap between application definition and implementation. Starting with a blank canvas, the Visual Composer user, typically a business process specialist, draws the application in Visual Composer Storyboard (workspace), without writing code, to prototype, design and produce applications. A typical workflow for creating, deploying and running an application using Visual Composer is: Create a model Discover data services and add them to the model Select necessary UI elements and add them to the model Connect model elements to define the model logic and data flow Edit the layout Arranging the UI elements and the controls of the application on forms and tables. Deploy the model This step includes compilation, validation and deployment to a selected environment. Run the application The application can run using different runtime environment (such as Adobe Flex and HTML). In 2014 a runtime environment was introduced that is utilizing HTML5 capabilities of SAPUI5.
Mobile DevOps
Mobile DevOps is a set of practices that applies the principles of DevOps specifically to the development of mobile applications. Traditional DevOps focuses on streamlining the software development process in general, but mobile development has its own unique challenges that require a tailored approach. Mobile DevOps is not simply as a branch of DevOps specific to mobile app development, instead an extension and reinterpretation of the DevOps philosophy due to very specific requirements of the mobile world. == Rationale == Traditional DevOps approach has been formed around 2007-2008, close to the dates when iOS and Android mobile operating systems were released to the public. The traditional DevOps approach primarily evolved to meet the changing needs of the software development world with the paradigm shift towards continuous and rapid development and deployment (such as in web development, where interpreted languages are more prevalent than compiled languages). While traditional DevOps embraced agility and flexibility, mobile operating system providers steered towards a walled-garden approach with compiled apps with tight controls over how they can be distributed and installed on a mobile device. This difference in the mobile development mindset compared to what the traditional DevOps approach is advocating, is augmented further with the mobile applications to be deployed on a high number of varying devices and operating systems. Eventually, the concept of Mobile DevOps took off as a trend around 2014-2015, in line with the fast growth of the number of applications in mobile app stores. As individuals and corporations alike are developing and publishing more and more mobile applications, the need for efficiency and shorter release cycles increased, which is addressed by the continuous feedback and continuous development approach within the concept of DevOps, while requiring a significant level of adaptation and extension of the traditional DevOps practices. == Mindset shift from traditional DevOps to mobile DevOps == Mobile DevOps has a unique set of challenges and constraints, which solidifies the fact that it needs to be approached as a separate discipline. These challenges can be outlined as follows: Platform-specific requirements and tight controls of mobile operating system providers, where for instance a macOS device is mandatory for iOS application development and release. The walled-garden approach of distributing mobile apps, specifically applying to iOS applications, which comes with app review and app release delays that would not be needed in web development, for instance. Code signing requirements that come with the walled-garden approach, which introduce additional processes in the mobile application build pipeline along with new security concerns. An entire deployment cycle is re-run even in the slightest code change due to how applications are compiled and delivered to the users. The final product is to be deployed to a wide variety of mobile devices worldwide, which requires extensive testing and user feedback. Monitoring mobile applications require additional tools and approaches to be able to get data from an application running on a mobile device while respecting user privacy. Frequent operating system updates by mobile platforms can require rapid adaptation of apps, introducing further complexity to the development and maintenance cycles. == Benefits of mobile DevOps == Mobile DevOps is not an abstract concept and offers a range of benefits that can help improve the efficiency and effectiveness of the mobile app development process. These benefits can even be quantified by collecting the data within the mobile application development lifecycle. The benefits can be categorized into the following areas: Faster Release Cycles: By automating tasks and streamlining the development process, mobile DevOps enables teams to deliver new features and updates more frequently. Improved Quality: Automated testing and continuous monitoring help to identify and fix bugs earlier in the development cycle, leading to higher quality apps. Optimized Resource Utilization: Mobile DevOps promotes optimized resource utilization by automating tasks and streamlining workflows. Furthermore, mobile DevOps practices like containerization can help to create more efficient and scalable development environments. Increased Agility: Mobile DevOps allows teams to be more responsive to changes in the market and user feedback. == List of Dedicated Mobile DevOps Platforms == Even though it is possible to run a mobile DevOps cycle with most of the CI/CD platforms, they may require significant effort compared to non-mobile CI/CD (e.g. you need to bring your own infrastructure or it may require "reinventing the wheel" for commonly used platforms like Jenkins). To overcome the mobile-specific challenges specified, there are certain platforms that are dedicated to the lifecycle of mobile applications. These platforms exclusively focus on DevOps processes for mobile app development and are also referred as mobile CI/CD platforms. Appcircle (Multiplatform | Cloud-based & On-premise) Visual Studio App Center (Multiplatform | Cloud-based) Xcode Cloud (Apple platforms only | Cloud-based)
Thai QR Payment
Thai QR Payment or PromptPay (พร้อมเพย์) is a real-time payment system in Thailand that allows money transfers through digital channels using identifiers linked to a bank account, including a mobile phone number, citizen identification number, tax identification number or bank account number. The system was introduced in 2016 as part of Thailand's national e-payment infrastructure and was developed under the National e-Payment Master Plan, a government programme intended to expand digital payment infrastructure and reduce the use of cash in everyday transactions. It is owned by National ITMX ltd and Bank of Thailand and developed by Vocalink, a group by Mastercard == History == PromptPay (originally AnyID) is one of the National e-Payment projects and policies by Thailand, to regulate and standardize electronic payments to follow the technologies with internet and smartphones that is expanding and bringing technology into Finance and Commerce. By 22 December 2015, The First Prayut cabinet have approved the project as a national infastructure PromptPay has also been used in cross-border payment linkages with other real-time payment systems in Southeast Asia. In April 2021, the Monetary Authority of Singapore and the Bank of Thailand launched a linkage between Singapore's PayNow and Thailand's PromptPay, allowing customers of participating banks to send money between the two countries using a mobile phone number. In June 2021, the central banks of Thailand and Malaysia launched a cross-border QR payment linkage between PromptPay and Malaysia's DuitNow system. == Services == PromptPay's Services have included Encrypted Transactions and Payment between Two Individuals (C2C) Government Infrastructure Payment Tax Returns Individual PromptPay e-Wallet Thai QR Payment Pay Alert e-Donation Cross Border QR Payment
Condensation algorithm
The condensation algorithm (Conditional Density Propagation) is a computer vision algorithm. The principal application is to detect and track the contour of objects moving in a cluttered environment. Object tracking is one of the more basic and difficult aspects of computer vision and is generally a prerequisite to object recognition. Being able to identify which pixels in an image make up the contour of an object is a non-trivial problem. Condensation is a probabilistic algorithm that attempts to solve this problem. The algorithm itself is described in detail by Isard and Blake in a publication in the International Journal of Computer Vision in 1998. One of the most interesting facets of the algorithm is that it does not compute on every pixel of the image. Rather, pixels to process are chosen at random, and only a subset of the pixels end up being processed. Multiple hypotheses about what is moving are supported naturally by the probabilistic nature of the approach. The evaluation functions come largely from previous work in the area and include many standard statistical approaches. The original part of this work is the application of particle filter estimation techniques. The algorithm's creation was inspired by the inability of Kalman filtering to perform object tracking well in the presence of significant background clutter. The presence of clutter tends to produce probability distributions for the object state which are multi-modal and therefore poorly modeled by the Kalman filter. The condensation algorithm in its most general form requires no assumptions about the probability distributions of the object or measurements. == Algorithm overview == The condensation algorithm seeks to solve the problem of estimating the conformation of an object described by a vector x t {\displaystyle \mathbf {x_{t}} } at time t {\displaystyle t} , given observations z 1 , . . . , z t {\displaystyle \mathbf {z_{1},...,z_{t}} } of the detected features in the images up to and including the current time. The algorithm outputs an estimate to the state conditional probability density p ( x t | z 1 , . . . , z t ) {\displaystyle p(\mathbf {x_{t}} |\mathbf {z_{1},...,z_{t}} )} by applying a nonlinear filter based on factored sampling and can be thought of as a development of a Monte-Carlo method. p ( x t | z 1 , . . . , z t ) {\displaystyle p(\mathbf {x_{t}} |\mathbf {z_{1},...,z_{t}} )} is a representation of the probability of possible conformations for the objects based on previous conformations and measurements. The condensation algorithm is a generative model since it models the joint distribution of the object and the observer. The conditional density of the object at the current time p ( x t | z 1 , . . . , z t ) {\displaystyle p(\mathbf {x_{t}} |\mathbf {z_{1},...,z_{t}} )} is estimated as a weighted, time-indexed sample set { s t ( n ) , n = 1 , . . . , N } {\displaystyle \{s_{t}^{(n)},n=1,...,N\}} with weights π t ( n ) {\displaystyle \pi _{t}^{(n)}} . N is a parameter determining the number of sample sets chosen. A realization of p ( x t | z 1 , . . . , z t ) {\displaystyle p(\mathbf {x_{t}} |\mathbf {z_{1},...,z_{t}} )} is obtained by sampling with replacement from the set s t {\displaystyle s_{t}} with probability equal to the corresponding element of π t {\displaystyle \pi _{t}} . The assumptions that object dynamics form a temporal Markov chain and that observations are independent of each other and the dynamics facilitate the implementation of the condensation algorithm. The first assumption allows the dynamics of the object to be entirely determined by the conditional density p ( x t | x t − 1 ) {\displaystyle p(\mathbf {x_{t}} |\mathbf {x_{t-1}} )} . The model of the system dynamics determined by p ( x t | x t − 1 ) {\displaystyle p(\mathbf {x_{t}} |\mathbf {x_{t-1}} )} must also be selected for the algorithm, and generally includes both deterministic and stochastic dynamics. The algorithm can be summarized by initialization at time t = 0 {\displaystyle t=0} and three steps at each time t: === Initialization === Form the initial sample set and weights by sampling according to the prior distribution. For example, specify as Gaussian and set the weights equal to each other. === Iterative procedure === Sample with replacement N {\displaystyle N} times from the set { s 0 ( n ) , n = 1 , . . . , N } {\displaystyle \{s_{0}^{(n)},n=1,...,N\}} with probability { π 0 ( n ) , n = 1 , . . . , N } {\displaystyle \{\pi _{0}^{(n)},n=1,...,N\}} to generate a realization of p ( x t | z 1 , . . . , z t ) {\displaystyle p(\mathbf {x_{t}} |\mathbf {z_{1},...,z_{t}} )} . Apply the learned dynamics p ( x t | x t − 1 ) {\displaystyle p(\mathbf {x_{t}} |\mathbf {x_{t-1}} )} to each element of this new set, to generate a new set { s t ( n ) } {\displaystyle \{s_{t}^{(n)}\}} . To take into account the current observation z t {\displaystyle \mathbf {z_{t}} } , set π t ( n ) = p ( z t | s ( n ) ) ∑ j = 1 N p ( z t | s ( j ) ) {\displaystyle \pi _{t}^{(n)}={\frac {p(\mathbf {z_{t}} |s^{(n)})}{\sum _{j=1}^{N}p(\mathbf {z_{t}} |s^{(j)})}}} for each element { s t ( n ) } {\displaystyle \{s_{t}^{(n)}\}} . This algorithm outputs the probability distribution p ( x t | z 1 , . . . , z t ) {\displaystyle p(\mathbf {x_{t}} |\mathbf {z_{1},...,z_{t}} )} which can be directly used to calculate the mean position of the tracked object, as well as the other moments of the tracked object. Cumulative weights can instead be used to achieve a more efficient sampling. == Implementation considerations == Since object-tracking can be a real-time objective, consideration of algorithm efficiency becomes important. The condensation algorithm is relatively simple when compared to the computational intensity of the Ricatti equation required for Kalman filtering. The parameter N {\displaystyle N} , which determines the number of samples in the sample set, will clearly hold a trade-off in efficiency versus performance. One way to increase efficiency of the algorithm is by selecting a low degree of freedom model for representing the shape of the object. The model used by Isard 1998 is a linear parameterization of B-splines in which the splines are limited to certain configurations. Suitable configurations were found by analytically determining combinations of contours from multiple views, of the object in different poses, and through principal component analysis (PCA) on the deforming object. Isard and Blake model the object dynamics p ( x t | x t − 1 ) {\displaystyle p(\mathbf {x_{t}} |\mathbf {x_{t-1}} )} as a second order difference equation with deterministic and stochastic components: p ( x t | x t − 1 ) ∝ e − 1 2 | | B − 1 ( ( x t − x ¯ ) − A ( x t − 1 − x ¯ ) ) | | 2 ) {\displaystyle p(\mathbf {x_{t}} |\mathbf {x_{t-1}} )\propto e^{-{\frac {1}{2}}||B^{-1}((\mathbf {x_{t}} -\mathbf {\bar {x}} )-A(\mathbf {x_{t-1}} -\mathbf {\bar {x}} ))||^{2})}} where x ¯ {\displaystyle \mathbf {\bar {x}} } is the mean value of the state, and A {\displaystyle A} , B {\displaystyle B} are matrices representing the deterministic and stochastic components of the dynamical model respectively. A {\displaystyle A} , B {\displaystyle B} , and x ¯ {\displaystyle \mathbf {\bar {x}} } are estimated via Maximum Likelihood Estimation while the object performs typical movements. The observation model p ( z | x ) {\displaystyle p(\mathbf {z} |\mathbf {x} )} cannot be directly estimated from the data, requiring assumptions to be made in order to estimate it. Isard 1998 assumes that the clutter which may make the object not visible is a Poisson random process with spatial density λ {\displaystyle \lambda } and that any true target measurement is unbiased and normally distributed with standard deviation σ {\displaystyle \sigma } . The basic condensation algorithm is used to track a single object in time. It is possible to extend the condensation algorithm using a single probability distribution to describe the likely states of multiple objects to track multiple objects in a scene at the same time. Since clutter can cause the object probability distribution to split into multiple peaks, each peak represents a hypothesis about the object configuration. Smoothing is a statistical technique of conditioning the distribution based on both past and future measurements once the tracking is complete in order to reduce the effects of multiple peaks. Smoothing cannot be directly done in real-time since it requires information of future measurements. == Applications == The algorithm can be used for vision-based robot localization of mobile robots. Instead of tracking the position of an object in the scene, however, the position of the camera platform is tracked. This allows the camera platform to be globally localized given a visual map of the environment. Extensions of the condensation algorithm have also been used to recognize human gestures in image sequences. This application of the condensation algorithm impacts the ran
Webmail
Webmail (or web-based email) is an email service that can be accessed using a standard web browser. It contrasts with email service accessible through a specialised email client software. Additionally, many internet service providers (ISP) provide webmail as part of their internet service package. Similarly, some web hosting providers also provide webmail as a part of their hosting package. As with any web application, webmail's main advantage over the use of a desktop email client is the ability to send and receive email anywhere from a web browser. == History == === Early implementations === The first Web Mail implementation was developed at CERN in 1993 by Phillip Hallam-Baker as a test of the HTTP protocol stack, but was not developed further. In the next two years, however, several people produced working webmail applications. In Europe, there were three implementations, Søren Vejrum's "WWW Mail", Luca Manunza's "WebMail", and Remy Wetzels' "WebMail". Søren Vejrum's "WWW Mail" was written when he was studying and working at the Copenhagen Business School in Denmark, and was released on February 28, 1995. Luca Manunza's "WebMail" was written while he was working at CRS4 in Sardinia, from an idea of Gianluigi Zanetti, with the first source release on March 30, 1995. Remy Wetzels' "WebMail" was written while he was studying at the Eindhoven University of Technology in the Netherlands for the DSE and was released early January 1995. In the United States, Matt Mankins wrote "Webex", and Bill Fitler, while at Lotus cc:Mail, began working on an implementation which he demonstrated publicly at Lotusphere on January 24, 1995. Customers who saw the cc:Mail demonstration were very enthusiastic, one recalling that they were "like an angry mob. People were yelling, 'We want this now!'". Matt Mankins, under the supervision of Dr. Burt Rosenberg at the University of Miami, released his "Webex" application source code in a post to comp.mail.misc on August 8, 1995, although it had been in use as the primary email application at the School of Architecture where Mankins worked for some months prior. Bill Fitler's webmail implementation was further developed as a commercial product, which Lotus announced and released in the fall of 1995 as cc:Mail for the World Wide Web 1.0; thereby providing an alternative means of accessing a cc:Mail message store (the usual means being a cc:Mail desktop application that operated either via dialup or within the confines of a local area network). Early commercialization of webmail was also achieved when "Webex" began to be sold by Mankins' company, DotShop, Inc., at the end of 1995. Within DotShop, "Webex" changed its name to "EMUmail"; which would be sold to companies like UPS and Rackspace until its sale to Accurev in 2001. EMUmail was one of the first applications to feature a free version that included embedded advertising, as well as a licensed version that did not. Hotmail and Four11's RocketMail both launched in 1996 as free services and immediately became very popular. === Widespread deployment === As the 1990s progressed, and into the 2000s, it became more common for the general public to have access to webmail because: many Internet service providers (such as EarthLink) and web hosting providers (such as Verio) began bundling webmail into their service offerings (often in parallel with POP/SMTP services); many other enterprises (such as universities and large corporations) also started offering webmail as a way for their user communities to access their email (either locally managed or outsourced); webmail service providers (such as Hotmail and RocketMail) emerged in 1996 as a free service to the general public, and rapidly gained in popularity. In some cases, webmail application software is developed in-house by the organizations running and managing the application, and in some cases it is obtained from software companies that develop and sell such applications, usually as part of an integrated mail server package (an early example being Netscape Messaging Server). The market for webmail application software has continued into the 2010s. == Rendering and compatibility == Email users may find the use of both a webmail client and a desktop client using the POP3 protocol presents some difficulties. For example, email messages that are downloaded by the desktop client and are removed from the server will no longer be available on the webmail client. The user is limited to previewing messages using the web client before they are downloaded by the desktop email client. However, one may choose to leave the emails on the server, in which case this problem does not occur. The use of both a webmail client and a desktop client using the IMAP4 protocol allows the contents of the mailbox to be consistently displayed in both the webmail and desktop clients and any action the user performs on messages in one interface will be reflected when the email is accessed via the other interface. There are significant differences in rendering capabilities for many popular webmail services such as Gmail, Outlook.com and Yahoo! Mail. Due to the varying treatment of HTML tags, such as