Хорошо!Я думаю, я понял это сейчас.
Вы правы, UDID, конечно, не отправляется браузером.Я также был убежден, что это было вызвано уязвимостью Safari или чем-то в этом роде, потому что testflightapp добавляет уникальный идентификатор, похожий на UDID, но нет.
Что они на самом деле делают, так это генерируют новый DeviceIDсвязано с UDID).Затем, чтобы зарегистрировать устройство, они генерируют профиль, специально созданный для этого DeviceID, который содержит Enrollment Payload , который регистрирует устройство по URL-адресу, содержащему этот DeviceID, созданный testflightapp.
InВ этом процессе регистрации устройство запрашивает профиль, чтобы отправить UDID (плюс другие данные).Это информация, которую запрашивает профиль:
<array>
<string>UDID</string>
<string>IMEI</string>
<string>ICCID</string>
<string>VERSION</string>
<string>PRODUCT</string>
<string>MODEL</string>
<string>DEVICE_NAME</string>
</array>
Итак, когда устройство запрашивает сервер testflightapp для регистрации этого устройства, они могут связать этот DeviceID, сохраненный в профиле, с фактическим UDID.текущего устройства.Вот как они показывают в браузере, что процесс завершен, и сохраняют UDID.
Но это не завершает ответ, потому что я еще не решил (пока), как они на самом деле связывают эту сетьсеанс с UDID, даже когда сеанс завершается, а DeviceID теряется.Кажется, ответ (не подтвержденный, но на 99% уверенный!) В том, что процесс регистрации позволяет определить веб-клип, который будет вставлен в меню Springboard.Этот веб-клип содержит в URL-адресе записанный UDID устройства, поэтому каждый раз, когда вы попадаете в testflightapp через этот веб-клип, вы обновляете для сеанса свой номер UDID, поэтому не имеет значения, если сеанс умирает.
Надеюсь мой пост поможет сейчас!Снова прошу прощения за неполно-дезинформированный предыдущий.