Inspected the official public LINE Chrome extension 3.7.2 on 2026-10-16,
matching ExtensionVersion, application headers, and the shared runtime default.
The dedicated capture profile has no installed manifest. Retrieved the public
package from Google's extension update service for
ophjlpahpchlmihnnnihgmmeilfjmjjc (official listing).
SHA-256: 3722ab02edb0aba49c229399ee8df5b4b5a38c60b76efadadfbae395015eb859.
This matches prior history/content/media evidence. Locators below refer to
minified symbols in this package's static/js/main.js. The software remains
copyright LY Corporation. No third-party source or account capture is committed.
Investigation contract: send one still image in a DM/group with encrypted and plaintext media capabilities; establish preparation, upload ordering, preview, metadata, receipts, and reply behavior. Static source resolved these questions, so no live login, message, or capture was performed. Synthetic tests verify the implementation against this contract; live interoperability remains unverified.
pp, Dk, CP, Lk, Rk, Ik, qk, and kk establish:
- Chrome accepts JPEG, PNG, GIF, and BMP based on its picker/type checks, with a 20 MiB image-input threshold. Original mode has a 100-million-pixel limit.
- Ordinary images are converted to JPEG at quality 0.6. The scale factor is
min(1, sqrt(1280*1280/(width*height))), with floored output dimensions. - A separate JPEG preview fits within 384脳384 without enlargement, rounded dimensions, at quality 0.3. Canvas uses a white background.
- Original/animated media take a separate
MEDIA_CONTENT_INFOpath.
The CLI deliberately accepts only JPEG and still PNG (actual decoded content,
not suffix), at most 20 MiB, 40 million decoded pixels, and 16384 pixels on either
axis. Decode configuration is checked before allocating the decoded image, then
full decoding must succeed. PNG acTL rejects animation. GIF/BMP/WebP and original
mode are outside this milestone. EXIF orientation is applied, metadata is removed,
and JPEG bytes plus a preview are prepared before session access. Browser and Go
JPEG encoders/resampling differ; byte parity is not claimed. These resource limits
are CLI policy, not claimed server limits. Use generic --file for original bytes.
LA.checkAndNegotiate, LA.checkAndGetMediaMessageFlow, lU, and ZU establish
TalkService/determineMediaMessageFlow with arguments [{"chatMid":"CHAT"}].
The success data has a flowMap keyed by decimal content type; image key "1"
returns 1 (plaintext) or 2 (encrypted). Chrome caches this with cacheTtlMillis.
The CLI reads it fresh for each image send with session read recovery. Missing,
malformed, unknown flow or transport failures stop the send. It permits plaintext
only for explicit flow 1, an explicitly non-E2EE session, or the existing explicit
Letter Sealing-unavailable signals. Flow 2 retains normal peer/group key validation
and complete membership before any required group registration. No failure of a
key, registration, upload, or send triggers plaintext fallback or mutation replay.
qC (enqueueFileMessages), sP, kP, PP, jP, VP, UP, and MP establish:
| Stage | Encrypted image (flow 2) | Plain image (flow 1) |
|---|---|---|
| Prepare | Resolve valid peer/group encryption keys | Explicit capability evidence |
| Full upload | POST /r/talk/emi/reqid-UUID |
After message creation |
| Preview upload | POST /r/talk/emi/OID__ud-preview |
Generated by server; no client preview upload |
| Message | sendMessage with content type 1, hasContent=true, encrypted payload |
sendMessage with content type 1, hasContent=true |
| Plain upload | Not used | POST /r/talk/m/MESSAGE_ID, OBS type image |
VP supplies base64 JSON X-Obs-Params with ver=2.0, a name, and type file
for encrypted bytes or image for plain images. Uploads use the encrypted OBS
access token and Chrome application headers. The full encrypted upload must
return x-obs-oid; absence is an unknown upload outcome and prevents later steps.
The preview must succeed before sending. There is no upload retry/resume in the
CLI, even though Chrome has UI retry facilities.
CL uses the same 32-byte key material for full and preview encryption, each
using FileEncryption HKDF, AES-CTR and HMAC-SHA256 as documented in
media download. The preview is a separately authenticated
object. jP supplies SID=emi, OID, normalized full-image FILE_SIZE, and
MEDIA_THUMB_INFO containing preview width/height. gL and EL place
keyMaterial and normalized fileName only in the encrypted payload, removing
ENC_KM and FILE_NAME from the outgoing outer metadata. e2eeVersion=2 is
retained. Plain image metadata is empty in the ordinary mode.
The CLI persists the message request sequence before sendMessage; OBS uses its
own random request ID, and the preview reuses the returned object ID. Outcomes
record attachment_upload, preview_upload, and send independently. A plain
image message already created remains confirmed if upload fails. Missing/lost
message receipts remain unknown. Success returns the established send receipt
with message/chat IDs, request sequence, and encryption status; no image keys,
chunks, object IDs, or raw server bodies are printed.
Chrome's compose handler adds reply relation fields to enqueueTextMessage and
enqueueStickerMessage, but calls the file/image enqueue path separately. qC
and sP construct media messages without a relation. This does not establish
server rejection or acceptance of image reply fields. The CLI therefore rejects
--image --reply-to before session access instead of claiming unverified support.
Text replies and existing generic-file behavior are unchanged. Text/stdin/file,
mentions, and image inputs cannot be combined.