JP5745599B2 - Input method editor - Google Patents

Description

  The present invention relates to an input method editor (IME).

IME is a computer program that is used together with a text editor, word processing software, and an application (for example, an application for inputting text such as a web browser) and supports character input in a predetermined language. There are IMEs for various languages such as Japanese and Chinese. Well-known IMEs include “MS-IME” from Microsoft, “Kotoeri” from Apple, “ATOK” from Just Systems, Wnn, Canna, etc. for Unix (registered trademark).

[1. Security issues]
The IME includes a plurality of functions including an event processing unit, a GUI (graphical user interface) display unit, and a text conversion unit. These functions are typically realized as monolithic components (software parts having specific functions). In Microsoft Windows®, this component is not a form that runs as a single process, but a single DLL (dynamic link library) that is loaded by the application. Therefore, this component is executed with the same authority as the application. If the IME component has a security hole, the attacker can illegally acquire the authority of the host application. This is a major security concern. For example, if a screen lock program such as winlogon.exe is attacked by an attacker using the IME vulnerability, the attacker can execute an arbitrary program using the privileges of the user who locked the screen. .

[2. Issues related to portability]
MS-IME (default IME for Windows®) and “Kotoeri” (default IME for Macintosh®) are based on a monolithic design. That is, all components are implemented as one binary file. This implementation makes internationalization (Internationalization, I18N) and porting more difficult. MS-IME and “Kotoeri” have different IME implementations for Chinese, Japanese, and Korean. Therefore, the MS-IME code is not shared between these languages.

  Wnn and Canna, well-known Japanese input methods for Unix, use a client-server model. However, the protocol between client and server has state and is Japanese-oriented. Wnn and Canna clients do not send raw keystrokes to the server. Therefore, IME client developers must carefully manage session information shared between the client and server. These IME protocols encode Japanese-specific information, making it more difficult to port the protocol to other languages including Chinese and Korean.

  The main challenges for implementing a portable input method that is language independent are:

  One challenge is that it is difficult to absorb differences in the IME framework. An “input method framework” must be used to implement the IME. However, different operating systems provide different input method frameworks. For example, Windows (registered trademark) provides IMM32 / TSF (text service framework), and Macintosh (registered trademark) provides IMKit. The APIs (application program interfaces) of these frameworks are different. Differences in input method frameworks make it difficult to port IMEs from one platform to another. Only Justsystem sells ATOK, which is an IME that runs on Windows (registered trademark) / Macintosh (registered trademark) / Linux (registered trademark). Other IME manufacturers, including open source IME developers, are concentrating on one platform because of the limitations of the non-portable IME framework.

  Another challenge is that it is difficult to absorb differences in IME usability in different languages. Different languages have different IME usability. The user needs to go through three intermediate states (basic input, pre-edit, conversion) to enter complete Japanese text. On the other hand, Chinese IME has only two states. In Japanese IME, it is necessary to support different key bindings (MS-IME format, Kotoeri format, etc.). For example, pressing the d key while holding down the Ctrl key corresponds to “delete” (single character deletion) in the Kotoeri format. Expanding to all possible key assignments, the size is 500. Chinese IME need not support such key assignments. The IME implementation is similar to the line editor implementation.

  Considering the realization of the IME in the client-server model in order to solve the above problems 1 and 2, the following problems 3 and 4 occur.

[3. Issues related to version update]
An IME designed in the client-server model has a problem when only the IME client is updated to a new version and the old version of the IME server is still running, or vice versa. If the IME client program is updated, but the existing application is still using an older version of the IME client (running an older version of the IME client program), two different IME clients are connected to one IME server. Access cases may occur. When the new version of the IME client does not support the old version of the communication protocol with the old version of the IME server, the IME client does not work. The same happens between the old version of the IME client and the new version of the IME server.

  A typical way to prevent such version mismatch is to restart the computer or log out and start all applications again. This is particularly annoying if it is expected to update the IME without the user's knowledge.

[4. Issues related to abnormal termination of IME server]
In a client-server type IME in which a stateless IME client sends each key input event to the IME server and receives output information, during the input session, when the IME server is abnormally terminated and restarted, The user can see unintended output.

  Some existing IMEs are implemented in a client-server model. However, these implementations do not consider server crashes and restarts.

The present invention first relates to a secure IME implementation with isolated processes.
Second, it relates to stateless session management for input method implementations that are language independent and portable.
Third, it relates to updating the IME version without restarting the computer.
Fourth, it relates to session playback.

[1. Solutions to security issues]
In the present invention, for the purpose of safety, the IME is separated into a plurality of processes (one client DLL and one server process as one form), and the function is modularized. Multiple processes can be applied with different security policies and different protection techniques such as sandbox, integrity level change.

Here, the “sandbox” is a technique that prevents a program from operating outside a protected area from being affected.
The “integrity level” is a security concept introduced in Microsoft Windows Vista (Windows is a registered trademark). This consistency level is divided into high, medium, and low, which determines how far the file system can be accessed as described below.
High: Can write to% ProgramFiles% and HKLM (administrator privileges).
Medium: Writing to% UserProfile% or HKCU is possible (user authority).
Low: Can only write to a dedicated location.

  In the present invention, the IME component is divided into an event processing unit, a GUI display unit, and a text conversion unit. In Windows (registered trademark), the event processing unit and the GUI display unit are one DLL component, but their functions are limited in order to reduce complexity. The text converter is an isolated process that runs in the sandbox with a lower integrity level. The text conversion unit includes a function of generating and transmitting display information for instructing display contents to the GUI display unit.

  For example, in Windows®, when a system tool having a “high” consistency level loads an IME component according to the present invention, the IME component is also executed at the “high” consistency level, which is the event processor. And only the GUI display section. The text converter is run in a sandbox with a “low” consistency level. Furthermore, the event processing unit and the GUI display unit can stop the connection with the text conversion unit according to the policy.

  In Apple's Macintosh (registered trademark), the event processing unit is a single process, so the problem is simpler than in Windows (registered trademark). The authority of the event processing unit can be controlled. In the present invention, by separating the event processing unit and the text conversion unit, the text conversion unit can be arranged in the sandbox to limit the function.

[2. Solution for portability issues]
An IME architecture that improves IME portability and internationalization is disclosed. In order to implement IME, the IME framework provided by each operating system must be used. These framework differences make IME porting difficult. In addition, the use of IME is different for different languages. It is known that it is difficult to make the IME architecture language independent. The present invention basically separates the IME into two components, a client and a server. In the present invention, a stateless protocol is used between the client and the server. The client and server communicate with each other using IPC (interprocess communication) or RPC (remote procedure call). All language-dependent IME models are implemented in the server, which need not depend on the IME framework. Since the protocol has no state, the role of the client can be simplified, and the client receives the user's key input event, transmits it to the server, and displays it according to display information from the server. A new IME for a new language can be realized simply by replacing the server part.

[3. Solution for problems related to version update]
The present invention is a technique for updating an IME realized without restarting a computer. When the new version of the IME client has a communication protocol that is compatible with the old version of the IME server, this update is made without the user's knowledge. When the new version of the protocol is not compatible with the old version of the protocol, it will detect it and prompt the user how to handle it.

[4. Solution for problem related to abnormal termination of IME server]
Even when the IME server instance terminates abnormally, the IME client can continue the current user session seamlessly by resending the previous key input event to the newly executed server.

  The IME according to the present invention has the following effects.

<Security>
The IME DLL operates at the same security level as the application. If the IME DLL has a security hole and the application is operating at a high security level (also called "high" integrity level in Windows Vista), then the malicious user / application is It is also possible to perform a malicious operation such as acquiring a user's personal data (user history data) using a security hole and transmitting it to an external server. In contrast, the client-server model according to the present invention can protect user data from malicious users / applications. Since the IME server according to the present invention is isolated, processes can be launched in a restricted sandbox environment. Sandboxed IME servers cannot access insecure resources on the local computer.

<Portability>
Different operating systems have different IME frameworks. In order to make the IME platform independent, it is desirable to minimize the dependency on these IME frameworks. Separating the core conversion engine as a separate process helps for portability.

<Robustness>
When an application crashes, the IME associated with the application is killed at the same time (program execution is terminated). Application crashes while the IME is synchronizing user history or any modifiable data to the local file system is a disaster. Conventional IME designs are weak in such cases. Sometimes an IME dictionary is corrupted due to an unintended application crash. In the present invention, there is no such concern. The IME client DLL according to the present invention does not perform a stateful operation, and the session information remains in the IME server even if the IME client DLL is killed. Therefore, user data can be safely synchronized with the local file system.

<Do not lock across processes>
One application creates an instance of one IME DLL. Traditionally, it always happens that there are multiple IME instances and uses shared resources such as dictionaries and user history, so IME DLLs are cross-excluded across processes to prevent concurrent use of shared resources Must use locks. In contrast, since the IME server according to the present invention is a single process for each user, the system itself does not need to lock across processes, which makes the IME much simpler than conventional systems.

Fig. 2 represents an IME architecture according to the invention. It is a figure showing the conventional IME architecture. 1 is a diagram representing an outline of an IME architecture according to the present invention; FIG. Represents a window that displays the path name of a named pipe. Represents a window that displays the access rights for a named pipe. It is a figure showing the operation | movement by the difference in a version.

  Hereinafter, embodiments of the present invention will be described in detail.

The IME executable file implemented in the client-server model includes an IME client program and an IME server program. The IME client can be considered to be realized by reading the IME client program into the computer and executing the instructions included in the program. The IME server reads the IME server program into the computer. It can be considered that it is realized by the computer executing the instructions included in.
The application in the description can be considered as an information processing apparatus constructed by loading an application program into a computer and executing instructions included in the program.
Note that the DLL (dynamic link library) in the description means the program itself, or the DLL is read by the computer and the computer can execute instructions included in the program. is there.

  The IME according to the present invention can be realized on a plurality of platforms. Hereinafter, Windows (registered trademark) will be mainly described as an example.

  The first embodiment will be described from the viewpoint of solving the security problem.

<IME architecture>
As shown in FIG. 1, an IME client according to an embodiment is implemented as a shared library (DLL) on Windows (registered trademark). This DLL is smaller in size than the conventional DLL shown in FIG. 2 that includes a conversion function. In the dotted line in FIG. 1 is a single IME server for each user operating in the sandbox. It is portable, has no global mutual exclusion, and is robust. On the other hand, the conventional IME architecture shown in FIG. 2 operates with the authority of the application, the conversion function is not portable, and the shared resource requires a mutual exclusion lock across processes, and is difficult to manage.

  When the application is launched by the user, the IME DLL is loaded into the computer's memory and combined with the application. The application calls the IME through the “IME framework”. IMM32 and TSF can be used as an IME framework on Windows (registered trademark). IME developers must implement transformation logic on the IME framework. As shown in FIG. 2, well-known IMEs such as MS-IME and ATOK have core IME translation logic in the DLL. Unlike these standard IMEs, the IME according to the present invention employs a local client-server model. The core conversion logic is executed as a separate process isolated from the application. A DLL coupled to an application (hereinafter referred to as an IME client DLL) implements a stateless display function. That is, the IME client DLL only serves to display candidate windows, highlight text, and obtain mouse / keyboard events from the user. The IME client DLL sends almost all keyboard / mouse events to the IME server process via IPC (interprocess communication) to obtain display information.

  The IME according to the present invention employs a portable client-server model. Here, the client-server is a local server on the OS, and provides a service for a client conversion request. Although it is not a server process on a remote computer, online conversion is also possible. Also, when supporting Windows®, Macintosh®, and Linux®, the client requires some platform-specific code, but the server should be as platform independent as possible. it can.

As shown in FIG. 3, the server is independent of the platform and performs all processing as much as possible.
The client is implemented using a platform-specific framework (for example, IMM32 or TSF for Windows (registered trademark)). The client is a thin client having a stateless event listener and a GUI display (in Windows (registered trademark), the event listener and the GUI display are also separated).
The client sends all key input events to the server, and the server returns display information to the client (in Windows (registered trademark), drawing information such as coordinates is added to the display information sent from the server, (Displayed on the GUI display section).

<Sandbox library>
The IME server process according to the present invention is launched in a secure sandbox. It can use the sandbox library used for Google Chrome (a web browser developed by Google).
The following is an example of program code related to the activation of the IME server process in the sandbox.

wchar_t mozc_server_path [MAX_PATH];
if (S_OK! = :: SHGetFolderPathW (NULL,
CSIDL_PROGRAM_FILES,
NULL,
SHGFP_TYPE_CURRENT,
mozc_server_path)) {
LOG (ERROR) <<"cannot find Program and Files";
return false;
}
wcsncat_s (mozc_server_path, MAX_PATH,
L "\\ Google \\ Mozc \\ mozc_server.exe",
_TRUNCATE);
HANDLE job_handle = 0;
// Create a Job inside restricted sandbox environment.
const DWORD err_code = sandbox :: StartRestrictedProcessInJob (
mozc_server_path,
sandbox :: USER_INTERACTIVE, // main token
sandbox :: USER_INTERACTIVE, // impersonate token
sandbox :: JOB_LOCKDOWN, // job token
sandbox :: INTEGRITY_LEVEL_LOW, // integritiy level
&job_handle);
if (ERROR_SUCCESS! = err_code) {
LOG (ERROR) <<"cannot launch mozc_server:"<< :: GetLastError ();
return false;
}

sandbox :: StartRestrictedProcessInJob () is a convenient static method that starts a process in the sandbox. This method receives three parameters: main_token_level, impersonate_token_level, and job_token_level. In the implementation of the present invention, the original code was modified so that the consistency level introduced after Windows Vista (Windows is a registered trademark) can be set.

<Preventing the IME server from being started as a normal process>
In order to prevent the IME server from being launched as a normal process, the IME server first checks whether its process is running in the correct sandbox environment. More specifically, the following sanity check is performed. When the return value is ServerUtil :: DENY, the IME server process is not started.
An example of the program code for sanity check is shown below.

HANDLE hToken = NULL;
// Open process token,
if (! :: OpenProcessToken (:: GetCurrentProcess (), TOKEN_QUERY, & hToken)) {
return ServerUtil :: DENY;
}
// If CurrentProcess doesn't have RESTRICTED token, return ServerUtil :: DENY
if (! :: IsTokenRestricted (hToken)) {
:: CloseHandle (hToken);
return ServerUtil :: DENY;
}
TOKEN_STATISTICS ts;
DWORD dwSize = 0;
// Use token logon LUID instead of user SID, for brevity and safety
if (! :: GetTokenInformation (hToken, TokenStatistics,
(LPVOID) & ts, sizeof (ts), & dwSize)) {
:: CloseHandle (hToken);
return ServerUtil :: DENY;
}
:: CloseHandle (hToken);
// Do not execute the server if i'm system
const LUID SystemLuid = SYSTEM_LUID;
const LUID LocalServiceLuid = LOCALSERVICE_LUID;
const LUID NetworkServiceLuid = NETWORKSERVICE_LUID;
if (EqualLuid (SystemLuid, ts.AuthenticationId) ||
EqualLuid (LocalServiceLuid, ts.AuthenticationId) ||
EqualLuid (NetworkServiceLuid, ts.AuthenticationId)) {
return ServerUtil :: DENY;
}
OSVERSIONINFO osi = {0};
osi.dwOSVersionInfoSize = sizeof (osi);
if (! :: GetVersionEx (& osi)) {
return ServerUtil :: DENY;
}
// Vista or later (Check the current session id is not 0)
if (osi.dwMajorVersion> = 6) {
// SessionId == 0 is special env.
DWORD dwSessionId = 0;
if (! :: ProcessIdToSessionId (:: GetCurrentProcessId (), & dwSessionId) ||
dwSessionId == 0) {
return ServerUtil :: DENY;
}
}
// mozc_server's main thread is impersonated.
if (! :: RevertToSelf ()) {
return ServerUtil :: DENY;
}
// OK my process is inside a safe environment!
return ServerUtil :: NORMAL;

<Client-server IPC>
In order to realize a client / server in a Windows (registered trademark) environment, it is recommended to use COM (Component Object Model). However, in the case of Windows Vista (Windows is a registered trademark), when the application is activated at the “high” consistency level, the IME COM server according to the present invention is also activated at the “high” consistency level. The same applies to the “low” consistency level and the “medium” consistency level. Therefore, in the case of Windows Vista (Windows is a registered trademark), three IME servers (COM instances) having different consistency levels are started simultaneously. In the client-server model according to the present invention, one IME server instance per user is a strong constraint and does not want a workaround that allows multiple instances.

<IPC model>
An IME according to one embodiment employs a single thread, single connection model. The IME server opens only one port and handles multiple connections from IME clients. The main reasons for adopting this model are simplicity and good portability. Almost all platforms support single thread, single connection IPC.

<Granularity of IPC>
The IME client sends all key input events (for example, the “A” key is pressed) to the server, and the display information corresponding to the key input event (for example, “A” is underlined). Display as “A” in Japanese.) Connection has no state. In general, the duration of an IPC connection is very short. When the IME server completes the display information response, it immediately closes the connection and waits for another connection.

<IPC timeout>
One of the challenges of the single connection / single thread model is that if a malicious user connects to the IME server and does nothing, the IME server will be blocked (preventing progress). . The reverse case can also occur. If the malicious IME server sends no response to the IME client, the IME client is blocked.
To prevent such cases, the IPC connection should execute a timeout. If the server / client does not send a message within a certain time (eg, within 500 milliseconds), the server / client closes the current connection. In Windows®, such a timeout is easily realized by using Overlapped I / O.
An example of the program code related to timeout is shown below.

bool SendIPCMessage (HANDLE handle,
const char * buf, size_t buf_length, int timeout) {
if (buf_length == 0) {
return false;
}
OVERLAPPED Overlapped;
:: ZeroMemory (& Overlapped, sizeof (Overlapped));
bool error = false;
while (buf_length> 0) {
if (! :: WriteFile (handle, buf,
static_cast <DWORD> (buf_length), NULL, & Overlapped) &&
ERROR_IO_PENDING! = :: GetLastError ()) {
error = true;
break;
}
if (WAIT_OBJECT_0! = :: WaitForSingleObject (handle, timeout)) {
LOG (WARNING) <<"Writetimeout:"<<timeout;
error = true;
break;
}
DWORD size = 0;
if (! :: GetOverlappedResult (handle, & Overlapped, & size, TRUE)) {
error = true;
break;
}
buf_length-= size;
buf + = size;
}
return! error;
}

<Path name of the named pipe>
Named pipes are one of the methods of inter-process communication in which executed programs exchange data inside a computer.
Named pipe pathnames should be unpredictable by other users. Otherwise, a malicious user can create a fake named pipe IME server before a valid IME server is started. In addition, malicious users can discover if the IME server is using the username to generate the path name, so it is not safe to use the username to generate the path name. Absent.

In an IME according to one embodiment, a 128-bit random path name is used. GetSecureRandomSequence () below is used to generate a path name. The standard rand () function is not safe because the results can be predictable.
An example of the program code related to path name generation is shown below.

bool Util :: GetSecureRandomSequence (char * buf, size_t buf_size) {
memset (buf, '\ 0', buf_size);
HCRYPTPROV hprov;
if (! :: CryptAcquireContext (& hprov,
NULL,
NULL,
PROV_RSA_FULL,
CRYPT_VERIFYCONTEXT)) {
return false;
}
if (! :: CryptGenRandom (hprov,
static_cast (buf_size),
reinterpret_cast (buf))) {
:: CryptReleaseContext (hprov, 0);
return false;
}
:: CryptReleaseContext (hprov, 0);
}

  FIG. 4 shows a process explorer window that displays a list of processes managed by the computer in Windows (registered trademark). If you look at the part surrounded by the bold line at the bottom of the window, you can see that a random number sequence is used for the path name of the named pipe.

<How the IME client DLL knows the path name>
When the IME server generates a path name for the named pipe, the path name is stored in the user profile directory. The location of the user profile directory is, for example, as follows. <User> represents a user name, and <IME> represents a unique name assigned to the IME.
For Windows XP (Windows is a registered trademark)
c: \ Document Setting \ <user> \ Local Settings \ Application Data \ google \ <IME>
For Windows Vista (Windows is a registered trademark) or Windows 7 (Windows is a registered trademark)
c: \ Users \ <user> \ AppData \ LocalLow \ google \ <IME>
For Linux (registered trademark) or Macintosh (registered trademark)
~ /. <IME> /

  Sharing keys in this user directory is basically secure, but there are some security concerns. In Windows Vista (Windows is a registered trademark), the LocalLow folder is considered the least secure place. Any process that runs at the “medium” / “high” consistency level should not trust the data in the LocalLow folder.

  Another concern is that a malicious application can store a fake pathname in the file before the IME server is started. The IME client DLL may connect to a malicious fake IME server. If a malicious application is run under the same user account, it cannot be protected from such a scenario. However, the lowest line is that security should be protected from malicious users / applications running under different user accounts. Some operating systems provide a platform-dependent way of knowing that an IME client DLL is connected to a valid IME server so that it can be used to the fullest it can. An example of its use is shown below.

1. The IME server locks the file holding the IPC path name. If the operating system provides a way to know the owner of the file lock, it can be used.
In the case of Windows®, there appears to be an undocumented way of knowing the owner, but it is not reliable and is not used.
In the case of Macintosh (registered trademark), there is no such API.
In the case of Linux®, the Linux® file lock is simply a recommendation lock. The file lock itself is not reliable.

2. If the operating system provides the process ID of the IPC partner, it can be used.
In the case of Windows Vista (Windows is a registered trademark), there is an API that knows the process ID of the other party, so you can use it (http://msdn.microsoft.com/en-us/library/aa365446(VS .85) .aspx).
In the case of Windows XP (Windows is a registered trademark), there is no equivalent API.
In the case of Macintosh (registered trademark), there is no equivalent API.
In the case of Linux (registered trademark), the pid of the other party can be known using a Unix Domain socket (Unix is a registered trademark). You can find the path by reading / proc / <pid> / exec.

3. Send PID via IPC.
Windows XP (Windows is a registered trademark) and Macintosh (registered trademark) have no support for knowing the pid of the other party, and can therefore send a PID via the IPC. This can prevent accidental attacks.

<Server connection should be single>
Multiple NamedPipe server instances (processes) with the same pathname using the CreateNamedPipe default parameters are allowed. This can be a fatal security hole. A malicious application can easily generate a fake IME server by using the same path name. In order to prevent the generation of multiple instances, the FILE_FLAG_FIRST_PIPE_INSTANCE flag was introduced after Windows XP (Windows is a registered trademark). Detail is
http://msdn.microsoft.com/en-us/library/aa365150(VS.85).aspx
See According to Microsoft, it is strongly recommended to set a flag.
http://support.microsoft.com/kb/308403/en
See

<Pass appropriate security attributes to CreateNamedPipe ()>
Named pipes should be accessed only by valid users. Pass valid security attributes to CreateNamedPipe API. As shown in FIG. 5, this allows access from the local system, administrator, and current user. Access from other users is not allowed. To know the implementation of MakeSecurityAttributes function
http: // s /? fileprint = // depot / google3 / experimental / mozc / third_party / sandbox / security_attributes.cc
See
An example of the program code related to calling CreateNamedPipe API is shown below.

SECURITY_ATTRIBUTES SecurityAttributes;
if (! sandbox :: MakeSecurityAttributes (& SecurityAttributes)) {
LOG (ERROR) <<"Cannot make SecurityAttributes";
return;
}
// Create a named pipe.
wstring wserver_address;
Util :: UTF8ToWide (server_address.c_str (), &wserver_address);
handle_ = :: CreateNamedPipe (wserver_address.c_str (),
PIPE_ACCESS_DUPLEX | FILE_FLAG_OVERLAPPED |
FILE_FLAG_FIRST_PIPE_INSTANCE,
PIPE_TYPE_MESSAGE |
PIPE_READMODE_MESSAGE |
PIPE_WAIT,
(num_connections <= 0?
PIPE_UNLIMITED_INSTANCES: num_connections),
sizeof (request_),
sizeof (response_),
0,
&SecurityAttributes);
if (handle_ == INVALID_HANDLE_VALUE) {
LOG (FATAL) <<"CreateNamedPipefailed"<< :: GetLastError ();
return;
}

<Preventing impersonation>
Named pipe spoofing must be disabled. Otherwise, the malicious IME server can impersonate the client connection and execute malicious code with client privileges. Pass the “SECURITY_SQOS_PRESENT | SECURITY_IDENTIFICATION | SECURITY_EFFECTIVE_ONLY” flag to the CreateFile API to disable spoofing of the named pipe. The following is an example of the program code for calling CreateFile API.

// Connecting to mozc server
handle_ = :: CreateFile (wserver_address.c_str (),
GENERIC_READ | GENERIC_WRITE,
0, NULL, OPEN_EXISTING,
FILE_FLAG_OVERLAPPED |
SECURITY_SQOS_PRESENT |
SECURITY_IDENTIFICATION |
SECURITY_EFFECTIVE_ONLY,
NULL);

  By passing these flags, the malicious IME server cannot impersonate the client connection.

<Session management>
Next, how the IME server according to the present invention manages a plurality of conversion requests from a plurality of applications will be described. An application opens a session that holds the current input mode, current conversion state, and so on. You must ensure that all sessions are isolated from each other.

<Session management protocol>
The IME client DLL first requests a session ID from the IME server. The session is managed using this session ID. For example, the key input event “a” is transmitted together with the session ID. The IME server can know which application (session) has received the key “a” by looking at the session ID. If it is no longer necessary to access the current session, the IME client can invoke the DeleteSession request.
IME client> CreateSession
IME server> Your session id is 123
IME client> SendKey 123 'a'
IME server> ...
...
IME Client> DeleteSession 123
Session messages are encoded into plaintext bytes by using protocol buffer 2 (an open source protocol buffer).

<Hiding your session information from other processes>
The session ID should be unpredictable from other applications. Otherwise, the malicious client can send a fake request and indirectly edit the session information. The IME server generates a random session ID (unsigned 64-bit integer) using the CreateRandomSequence function described above. Although it is possible to obtain a valid ID by brute force attack, it is much safer than using a predictable session ID (sequential ID, etc.).

<Preventing DoS (Denial of Service) attacks>
When a malicious client sends a large number of fake CreateSession requests, the IME server consumes heap memory and eventually crashes. In order to prevent such a case, all session IDs are managed by a kind of fixed LRU (least recently used) cache. For example, the size is set to 64. When the effective session size reaches 64, the IME server deletes the oldest session. This process does not always prevent all DoS attacks on the CreateSession request, but at least prevents unintended memory consumption. In addition, the following processing can be added to stop the DoS attack.
-When CreateSession is called, no other CreateSession can be requested within 1 second (1 second is optional).
When the IME client does not send a request (such as SendKey) for 30 seconds, the session is automatically deleted. This process erases the zombie session.
When the IME client does not send a request for 2 minutes after CreateSession, the session is automatically deleted.
• The IME client DLL should be robust enough to maintain the transformation even when the session is cleared by the IME server.

  Next, the second embodiment will be described from the viewpoint of solving the portability problem.

  In the present invention, a client-server model is adopted to realize the IME function. One reason is portability. The IME server according to the present invention is configured such that the core functions of the IME are coded as portable as possible, and the functions are arranged in one process, so that various operating environments (Windows (registered trademark), Macintosh ( (Registered trademark), Linux (registered trademark)), it is not necessary to know the function of the operating system, and provides the function in its own way. Some IME server routines obscure the IME server interface and process the IME API for each operating system.

  The IME server handles all IME functions. This provides Romaji-kana conversion (or other input methods), metacommands like F7, Kana-Kanji conversion, user history learning, annotations, predictive input, and any other functions. The IME client handles the interaction with the user. The IME client can be considered to play the role of event listener and GUI display function.

  In other words, the IME server according to the present invention is a function-rich server (fat server) that processes everything as much as possible without depending on the platform. In contrast, IME clients are implemented using platform-specific frameworks (eg, IMM32 or TSF for Windows®) and serve as stateless event listeners and GUI display functions for all keystrokes. It is a thin client that transmits an event to an IME server and displays it using display information returned from the IME server.

  Even if there is only one text application for the user to enter text, there can be multiple applications on the user's desktop, and the user often switches the focused application while entering text. Therefore, it is desirable to maintain the input state for each text application. The IME server according to the present invention can accept multiple requests and process them. Each input state is called a “session”, and the session is identified by a session ID which is a number.

  The IME server according to the present invention does not support keep-alive connections. An IME client according to the present invention creates a connection to an IME server, sends a command, receives a response, and disconnects. Therefore, each command must include a session ID. One exception is a command called “CreateSession”. When the IME client calls this command without a session ID, the IME server creates a session and returns the session ID to the IME client.

<Start server process>
IME clients share an IME server. If the IME server has not been started yet, the IME client starts the IME server. Each user connects to each IME server. Users do not share the IME server. Multiple computers do not share an IME server on one of them. Thus, the client-server connection is closed within one computer. There is one IME server even when one computer has multiple desktops. The IME server can store data such as user history in the user's home directory. However, in this case, for example, the home directory should not be shared among a plurality of computers using NFS (Network File System).

One IME server process for one login user.
One IME server process for multiple desktops on one computer. Note that when two computers access one user profile, consideration is required.
One conversion unit instance for one IME server process. That is, the conversion unit is a single unit.
-Multiple connections to one server process.
・ The connection is one-shot and keep-alive is not performed.
A context (session) is managed by a session ID.
When two applications use the same session ID, there is no need to lock the session ID because the IME server is one thread.
The IME server is a single thread.
• All methods in the converter must be thread safe. If there is an exclusive action, lock.

  This IME architecture consists of two components: an “IME client” and an “IME server”. The IME client and the IME server are executed in different contexts, eg, different processes and / or different computers.

<IME client>
The IME client is realized on an IME framework provided by each operating system. The IME client performs the acquisition of the user's key input event (for example, the key “a” is pressed), transmits the key input event to the IME server, and the IME server transmits the client. Display information corresponding to the key input event (for example, display the Japanese “a” with an underscore) is returned, so that it is only displayed. The IME client does not manage state.

  Since the role of the IME client according to the present invention is limited, the dependence on the IME framework is much less than other IME clients. Implementation of an IME client according to the present invention is easier than other IME clients.

  The IME client displays a list of candidates from which the user selects an appropriate candidate. The IME client can use any implementation to display this list. As for the web application, Ajax (Asynchronous JavaScript + XML (JavaScript is a registered trademark)) and JavaScript (JavaScript is a registered trademark) can be used.

<IME server>
The IME server is executed in a different process from the IME client. If RPC is used for connection, the IME server can be run on a different computer. Since the IME server does not need to be implemented on an arbitrary IME framework, the implementation of the IME server is more portable. Different IME clients running on different platforms can connect to the same IME server. The IME server processes all key input events and returns display information to the IME client. The display information includes the current (partially) converted Japanese text to be displayed in the application and the contents of the candidate window.

Here, an example of a protocol sequence between the IME client and the IME server is shown. The session ID is used to identify different IME clients.
1. IME client-> IME server: Create a new session.
2. IME server → IME client: OK. Your session ID is 123.
3. IME client → IME server: 'a' was pressed. ID is 123.
4). IME server-> IME client: Underline the current line and display "A".
5). IME client → IME server: 'i' was pressed. ID is 123.
6). IME server-> IME client: Underline the current line and display "Ai".
7). IME client-> IME server: '' (blank) was pressed. ID is 123.
8). IME server-> IME client: Display “love” on the current line.
9. IME client-> IME server: '' (blank) was pressed. ID is 123.
10. IME server-> IME client: "Love" is displayed on the current line, and the content is [Ai, Go, Ai, Ai,. . . ], And highlight the first candidate.
11. IME client → IME server: “down” key was pressed. ID is 123.
12 IME server-> IME client: "Go" is displayed on the current line, and the contents are [Go, Ai, Phase,. . . ], And highlight the second candidate.
13. IME client → IME server: “enter” key was pressed. ID is 123.
14 IME server-> IME client: Send the text "go" to the application.
15. ...
16. IME client → IME server: The session 123 is deleted.
17. IME server → IME client: OK. End.

  In step 1, the IME client creates a new session. The IME server issues a new session ID, which is used to identify each IME client. When the user presses the 'a' key, the information is sent directly to the server. The IME server returns that the Japanese hiragana “a” should be displayed on the current line. Subsequently, when the user presses the “i” key, in step 6, the IME server returns that “Ai” should be displayed. “Ai” corresponds to the key input sequence of the user transmitted in Step 3 and Step 5. That is, “ai” corresponds to “ai”.

  For IME clients, step 3 and step 5 are completely independent in the sense that the protocol is stateless. In Japanese IME, '' (blank) is assigned to the “conversion” key. In step 8, the IME server returns the most likely Japanese text whose pronunciation is “ai”. In step 9, the user again tries to expand all possible candidates by pressing white space. In step 10, the IME server returns a list of all candidates with the same pronunciation “ai”.

  Implementation of new IMEs for other languages is easy using the architecture described above. Since all language dependent parts are implemented in the IME server, the implementation of the IME client can be reused. Reusing the IME client implementation is good for portability.

  The example of the client-server model using the IPC has been described above, and the architecture based on the IPC is shown in FIG. 1, but the IPC portion can be replaced with RPC.

  Next, a third embodiment will be described from the viewpoint of solving the problem related to version update.

An IME version and a protocol version are assigned to the IME client and the IME server. If the protocol version of one of the IME client and IME server is updated, they cannot communicate. Protocol version updates are less frequent than IME version updates. In other words, even if the IME version is updated, the protocol version may not be updated. However, when the protocol version is updated, the IME version is also updated.
The version of the protocol is stored in an .ipc file such as a file name “.session.ipc”, for example. The .ipc file is a message serialized with protobuf. If you want to update the protocol buffer (http://code.google.com/p/protobug/), modify the ipc / ipc.h file. There is an enumerated IPC_PROTOCOL_VERSION field. The IME client and IME server versions are encoded, for example, in a binary executable file. The .ipc file also encodes the IME client and IME server versions.

  The IME client according to the present invention checks the protocol compatibility with the operating IME server and the version of the operating IME server. The IME client changes its behavior based on this compatibility and version. There can be four cases:

<Case 1>
If the IME client version is the same as the IME server version, this is a normal case and no special action is taken.
<Case 2>
If the IME client version is newer than the IME server version, the IME client restarts the IME server. That is, the execution of the IME server program is stopped, and a new program version of the IME server program is read into the memory and executed.
<Case 3>
If the IME client version is older than the IME server version and the protocols are compatible, the IME client maintains a connection with the IME server.
<Case 4>
If the IME client version is older than the IME server version and the protocol is not compatible, the IME client aborts the connection with the IME server.

  In cases 1, 2, and 3, the IME server can be updated safely. In case 4, the old version of the IME client cannot connect to the new version of the IME server. However, this can be a rare case for normal updates. Case 4 does not occur if the new version of the IME server supports both new and old versions of the protocol.

For example, when an application program is executed after an IME executable file (IME client program (DLL as one form) and an IME server program) saved in a computer storage device is updated, a new version of the IME client program Is executed. The new version of the IME client checks the version of the IME server and the version of the protocol (FIG. 6A).
When the new version of the IME client detects that the version of the operating IME server is old, the new version of the IME client stops the old version server and starts a new version of the IME server (FIG. 6B).
On the other hand, when the IME client operating with the application before the update of the IME executable file detects that the version of the operating IME server is newer than the version of the IME client, the IME client detects the protocol of the IME server. The compatibility of the protocol is checked with reference to the version (FIG. 6C).
If the protocols are compatible, the IME client connects to a new version of the IME server (FIG. 6 (d)). If not, the IME client stops the connection and informs the user of the version mismatch (FIG. 6 (e)).

  In FIG. 6, “old client (server)” refers to an IME client (server) program having an older IME version operated on a computer, and “new client (server)” refers to the IME version. This means that a new IME client (server) program is run on a computer.

  The above processing will be described in detail separately for the case where the protocol version and the IME version are updated and the case where only the IME version is updated in the update of the executable file.

<When protocol version and IME version are updated>
1. Omaha (a Google program that automatically installs a new version of a program) moves the IME client DLL and the IME server program stored in the storage device of the computer and changes the file name. A new IME client DLL and IME server program are stored in the storage device of the computer.
2. The newly started application reads a new version of the IME client DLL into the memory.
3. When the IME client sends a CreateSession command, a protocol version mismatch can be detected by checking the .ipc file.
4). If the IME client version is newer than the IME server (running IME server) version, the IME client restarts the IME server without the user's knowledge. The restart is executed only when the CreateSession command is sent.
5). If the protocol version or IME version does not change after restart, a dialog window indicating an error is displayed on the computer display.
6). The original application that has read the old version of the IME client DLL into the memory of the computer cannot communicate with the new version of the IME server. In this case, ie, if the IME client protocol version is older than the IME server version, the IME client displays a dialog window indicating an error on the computer display.

<When only IME version is updated>
1. Omaha moves the IME client DLL and the IME server program stored in the storage device of the computer to change the file name. A new IME client DLL and IME server program are stored in the storage device of the computer.
2. The newly started application reads a new version of the IME client DLL into the memory.
3. When the IME client sends a CreateSession command, a protocol version mismatch can be detected by checking the .ipc file.
4). Because the protocol versions are compatible, the IME client can safely restart the IME server. The restart is executed only when the CreateSession command is sent.
5). If the version of the IME server does not change after the restart, a dialog window indicating an error is displayed on the computer display.
6). The original application that reads the old version of the IME client DLL into the memory of the computer uses the old version of the IME client program. This is not a big problem because only the IME server is updated when another application sends a CreateSession command, that is, the IME server is not updated while the user is typing. Compatible protocol versions also ensure that client-server communication is not destroyed.

  In the above description, the program version and the protocol version are used to specify the correspondence between the client and the server. However, other information may be used.

  Next, a fourth embodiment will be described from the viewpoint of solving the problem related to abnormal termination of the IME server.

  The present invention includes means for restarting an IME server, means for detecting restart of the IME server, means for transmitting a previous key input string from the IME client when the IME server is restarted, Means for preventing an infinite loop caused by sending a crashed key input sequence, and means for recording a key input sequence that causes the IME server to crash.

  In the client-server type IME according to the present invention, the IME server recognizes the state, receives a key input event, and returns display information. The IME client is stateless and sends each user keystroke event to receive display information from the server and display it on the appropriate user interface. When the user turns on the IME, the IME server must be running, and even when the IME server terminates abnormally, the IME server is restarted from the IME client. The IME client according to the present invention keeps the key input sequence during the input session and resends it when the IME server is restarted.

  The present invention can be used for IME.

  1, 2, 3 ... Application

Claims (5)

A computer-implemented method comprising:
Establishing a first session between a first input method editor (IME) client and a first IME server , wherein the first IME client version and the first IME server version are: Equal, step ,
Requesting a second session between a second IME client and the first IME server;
Determining that the version of the first IME server is different from the version of the second IME client;
In response to determining that the version of the first IME server is different from the version of the second IME client, stopping the first IME server;
Creating an instance of a second IME server having the same version as the version of the second IME client ;
Stopping the first session;
Determining whether the protocol version of the first IME client is compatible with the protocol version of the second IME server;
If it is determined that the protocol version of the first IME client is compatible with the protocol version of the second IME server, a fourth version is established between the first IME client and the second IME server. A method comprising establishing a session .   The computer-implemented method of claim 1, further comprising establishing a third session between the second IME client and the second IME server. Generating an error in the first IME client if it determines that the protocol version of the first IME client is not compatible with the protocol version of the second IME server; A method executed by the computer according to Item 1.   The computer-implemented method of claim 1, wherein the first IME client, the second IME client, the first IME server, and the second IME server are executed on a common device.   Determining that the version of the first IME server is different from the version of the second IME client determines that the version of the first IME server is older than the version of the second IME client; The computer-implemented method of claim 1, comprising the steps.