😮 Recent changes to post-login initialization ?

[clins1994]

On a recent network traffic analysis I found that post-login initialization step used TalkService/getE2EEPublicKeysEx on the line chrome extension but we use a combination of getE2EEPublicKey and negotiateE2EEPublicKey.

Questions

• Should we change it to use TalkService/getE2EEPublicKeysEx ?
• Should we upgrade LINE Chrome Extension to 3.7.2 instead of 3.7.1 ?

Post-Login Initialization

Method	Status	Bridge Status
TalkService/getProfile	200	Implemented
TalkService/getEncryptedIdentityV3	200	Implemented
TalkService/getServerTime	200	Not implemented (not critical)
TalkService/getLastOpRevision	200	Implemented
TalkService/getConfigurations	200	Not implemented
TalkService/getSettings	200	Not implemented
TalkService/getE2EEPublicKeysEx	200	Not implemented (we use getE2EEPublicKey and negotiateE2EEPublicKey)

To be discussed ... Below is the complete traffic analysis for reference

---

Traffic Analysis

Login Flow (in order)

Method	Status	Bridge Equivalent
SecondaryQrCodeLoginService/createSession	200	pkg/line/client.go — implemented
SecondaryQrCodeLoginService/createQrCode	200	pkg/line/client.go — implemented
SecondaryQrCodeLoginPermitNoticeService/checkQrCodeVerified	—	pkg/line/client.go — implemented
TalkService/getRSAKeyInfo	200	pkg/line/client.go — implemented
AuthService/loginV2	200	pkg/line/methods.go — implemented
AuthService/logoutV2	200	Not implemented (we don't log out)

Post-Login Initialization

Method	Status	Bridge Status
TalkService/getProfile	200	Implemented
TalkService/getEncryptedIdentityV3	200	Implemented
TalkService/getServerTime	200	Not implemented (not critical)
TalkService/getLastOpRevision	200	Implemented
TalkService/getConfigurations	200	Not implemented
TalkService/getSettings	200	Not implemented
TalkService/getE2EEPublicKeysEx	200	Not implemented (we use getE2EEPublicKey and negotiateE2EEPublicKey)

Contact & Chat Discovery — the key finding

Method	Status	Bridge Status
TalkService/getAllContactIds	200	NOT IMPLEMENTED — returns all friend MIDs
TalkService/getAllChatMids	200	Implemented
TalkService/getMessageBoxes	200	Implemented
TalkService/getContactsV2	200	Implemented (but needs the MIDs from above)
TalkService/getChats	200	Implemented

E2EE

Method	Status	Bridge Status
TalkService/getE2EEGroupSharedKey	200	Implemented
TalkService/getLastE2EEPublicKeys	200	Not implemented (we use per-peer negotiation)

Other Services

Method	Status	Bridge Status
BuddyService/getBuddyDetail	400	Not implemented — official accounts/bots detail
ShopService/getOwnedProductSummaries	200	Not implemented — sticker packs (not needed)
Long-poll SSE /api/operation/receive	200	Implemented in pkg/line/sse.go
/api/lan/notice	200	Not implemented — LINE notifications/announcements

[clins1994]

CDP Capture Follow-up (2026-04-08)

Ran a second capture using the CDP-based script (scripts/line-cdp-capture.py) which captures full request/response JSON bodies — unlike the net-log capture which only gets connection-level metadata.

Key finding: getE2EEPublicKeysEx was NOT called this session

The Chrome Extension (v3.7.2) did not call getE2EEPublicKeysEx during this session's startup. Instead it used:

1. getLastE2EEPublicKeys — a bulk fetch that takes a single token string and returns a map of MID → E2EEPublicKey for recently-updated keys:

   • Request: ["<session/cache token>"]
   • Response: {"code":0, "data": {"<mid1>": {"version":1, "keyId":..., "keyData":"...", "createdTime":"..."}, "<mid2>": {...}, ...}}

2. Individual getE2EEPublicKey calls (9 of them) for specific contacts — same as what the bridge already uses.

This suggests getE2EEPublicKeysEx may only be called on first login or when the local key cache is completely cold. getLastE2EEPublicKeys appears to be the steady-state bulk key sync method.

Also confirmed: getAllContactIds

Full request/response captured:

• Request: [2]
• Response: returns all friend MIDs (1000+ contacts in one call)

This is the missing piece for proper contacts sync — much better than getMessageBoxes which caps at 100 recent conversations.

Next steps

• Implement getAllContactIds (trivial — single arg [2], returns MID list)
• Implement getLastE2EEPublicKeys (bulk key fetch, returns MID→key map)
• Consider another capture with cleared extension storage to trigger getE2EEPublicKeysEx and understand its cold-start role

[clins1994]

There seems to be a difference between cold starts and subsequent logins for the bulk encryption key fetcher

cc @highesttt working on supporting this at the moment, seems like the number one priority. let me know if you are working on it already

Continuing ... Testing a fresh cold start run and getting the payloads. Will post here as I find stuff

[clins1994]

Current hypothesis

1. getE2EEPublicKeysEx only appears for the LSOFF user on first login after April 1st ... It was the first login on the LINE Chrome Extension after April 1st
2. getE2EEPublicKeyEx is never used users who were already LSON users before April 1st

Doing a login with the former LSOFF to see if it still calls it

[clins1994]

LSOFF Login Report

4 digit PIN Code appeared, strange. And no E2EE related calls after logging in ... Super confusing. Did they revert the Letter Sealing for everyone feature? 🫠

No getE2EEPublicKeysEx. And notably — zero E2EE key calls at all. No getE2EEPublicKey, no getLastE2EEPublicKeys, no negotiateE2EEPublicKey. This LSOFF user doesn't do any E2EE key fetching because letter sealing is off — messages aren't encrypted.

So your hypothesis is looking strong: getE2EEPublicKeysEx was likely called during the first login after April 1st when the LSOFF user was migrated to LSON — a one-time key bootstrapping call to fetch public keys for all contacts at once during the migration.

For the bridge this means:
  - getE2EEPublicKeysEx — one-time migration, not needed for steady-state (assumption)
  - getLastE2EEPublicKeys — bulk key delta sync, used by LSON users on every session
  - getAllContactIds — full friend list, used by both LSON and LSOFF users

Checking news ... :x EDIT: no news found

[clins1994]

getSettings response from LSOFF user (2026-04-08)

Note e2eeEnable: false — this account still has letter sealing disabled. No E2EE key calls were made during this session. No "Letter Sealing" toggle button appears in settings ... 🤷‍♂️ I'll revisit this after a while

{
  "code": 0,
  "message": "OK",
  "data": {
    "notificationEnable": true,
    "notificationMuteExpiration": "-1",
    "notificationNewMessage": true,
    "notificationGroupInvitation": true,
    "notificationShowMessage": true,
    "notificationIncomingCall": true,
    "notificationDisabledWithSub": true,
    "notificationPayment": true,
    "notificationMention": true,
    "notificationThumbnail": true,
    "notificationBadgeTalkOnly": false,
    "notificationReaction": true,
    "notificationShowProfileImage": true,
    "privacySyncContacts": false,
    "privacySearchByPhoneNumber": false,
    "privacySearchByUserid": true,
    "privacySearchByEmail": false,
    "privacyAllowSecondaryDeviceLogin": true,
    "privacyProfileImagePostToMyhome": false,
    "privacyProfileMusicPostToMyhome": false,
    "privacyReceiveMessagesFromNotFriend": true,
    "privacyAgreeUseLineCoinToPaidCall": false,
    "privacyAgreeUsePaidCall": false,
    "privacyAllowFriendRequest": true,
    "privacyAllowNearby": false,
    "privacySharePersonalInfoToFriends": 1,
    "privacyAgeResult": 1,
    "privacyAgeResultReceived": true,
    "privacyAllowFollow": true,
    "privacyShowFollowList": false,
    "contactMyTicket": "<redacted>",
    "identityProvider": 1,
    "identityIdentifier": "<redacted>",
    "snsAccounts": {},
    "phoneRegistration": true,
    "emailConfirmationStatus": 3,
    "accountMigrationPincodeType": 0,
    "enforcedInputAccountMigrationPincode": false,
    "securityCenterSettingsType": 0,
    "allowUnregistrationSecondaryDevice": false,
    "pwlessPrimaryCredentialRegistration": false,
    "preferenceLocale": "ja",
    "customModes": {},
    "e2eeEnable": false,
    "hitokotoBackupRequested": false,
    "agreementNearbyTime": "-1",
    "agreementSquareTime": "<redacted>",
    "botUseAgreementAcceptedAt": "<redacted>",
    "agreementShakeFunction": "-1",
    "agreementMobileContactName": "0",
    "agreementSoundToText": "0",
    "privacyPolicyVersion": "13.0.0",
    "agreementAdByWebAccess": "<redacted>",
    "agreementPhoneNumberMatching": "<redacted>",
    "agreementCommunicationInfo": "<redacted>",
    "agreementThingsWirelessCommunication": "0",
    "agreementGdpr": "-2",
    "agreementProvideLocation": "<redacted>",
    "agreementBeacon": "<redacted>",
    "agreementContentsSuggest": "-1",
    "agreementContentsSuggestDataCollection": "-1",
    "agreementOcrImageCollection": "-1",
    "agreementIcna": "-2",
    "agreementMid": "<redacted>",
    "agreementPdp": "-2",
    "agreementPdpa": "-2",
    "agreementLocationVersion": "1.0.0",
    "agreementSnowAiAvatar": "0",
    "agreementAlbumUsageData": "<redacted>",
    "agreementAlbumUsageDataVersion": "1",
    "agreementLypPremiumAlbum": "<redacted>",
    "agreementLypPremiumAlbumVersion": "1",
    "agreementLypPremiumBackup": "<redacted>",
    "agreementLypPremiumBackupVersion": "1",
    "agreementPremiumBackupPremiumType": "LYP_PREMIUM",
    "agreementOaAiAssistant": "0",
    "agreementOaAiAssistantVersion": "1",
    "agreementLypPremiumMultiProfile": "0",
    "agreementLypPremiumMultiProfileVersion": "0",
    "agreementLineOutUse": "0",
    "agreementLineOutProvideInfo": "0",
    "homeNotificationNewFriend": true,
    "homeNotificationFavoriteFriendUpdate": true,
    "homeNotificationGroupMemberUpdate": true,
    "homeNotificationBirthday": true,
    "homeNotificationNoteNoteLike": true,
    "homeNotificationNoteComment": true,
    "homeNotificationNoteCommentLike": true,
    "homeNotificationNoteMention": true,
    "eapAllowedToConnect": {
      "1": false,
      "6": false
    },
    "zhdPageAllowedToShow": false,
    "eapOnlyAccountTargetCountry": false,
    "agreementPremiumAlbumPremiumType": ""
  }
}

[clins1994]

Closing this to make a more organized discussion for educational purposes