Pull to refresh
73
0
Павел Малинников @Malinnikov

Пользователь

Send message
Скорее, все шифруется хешем пароля от iCloud. А Touch ID — это чисто локальная для девайса вещь, она даже никуда не передается по сети.

Чтобы ее «украсть», надо не только украсть физически процессор из девайса, но и как-то переместить данные из его secure enclave в защищенную область другого процессора.

Пока таких случаев известно не было, насколько я знаю.
Нет, не только браузерных полей. И на iOS и на Android есть возможность автоматического заполнения полей и в нативных приложениях.

Авторизация на телефоне через распознавания лица, на компьютере — распознавание пальца. Конечно, мастер-пароль есть, но это не «общий случай».

И конечно, компроментации этого пароля недостаточно чтобы все пароли улетели. Вход в iCloud, где пароли хранятся и синхронизируются между устройствами, защищен двухфакторной авторизацией.
Я пароли даже не то, чтобы забываю — я их изначально не знаю. Просто соглашаюсь с тем, который автоматически генерируется при регистрации и тот же пароль автоматически подставляется впоследствии на этом сайте, если даже я потом зашел туда с телефона.

Понятно, что для этого нужно авторизоваться, например, телефон должен узнать меня в лицо и я должен смотреть на экран в этот момент.

Конечно, раньше я тоже помнил пароли, имел системы их придумывания/вспоминания. Но все равно образуется какой-нибудь текстовый файлик в запароленном архиве с секретными данными, типа кодов восстановления двухфакторной авторизации и проч.

Но после того, как 10 лет назад я увидел, что можно это организовать на системном уровне в виде Связки ключей или другого менеджера паролей, я предпочитаю использовать эти решения.
Хорошая память — это отлично, но у меня около 650 сохраненных паролей типа «7qq-gRW-73m-tqn» и моя память, видимо, уже достаточно дырява, чтобы это запомнить.

Именно поэтому мне кажется использование менеджеров паролей очень оправданным. В Эппл-экосистеме одно и то же хранилище используется для автозаполнения паролей в мобильных приложениях. Причем, в последнее время для автозаполнения достаточно распознавания лица или пальца.

Бекап хранилища ничем не отличается от бекапа обычного файла.

Другие экосистемы тоже имеют свои менеджеры паролей. Для Андроида, например, точно есть.
Конечно, один пароль, для логина (он же от хранилища паролей) надо знать, но мы все же находимся в контексте ввода паролей в браузере.
Если речь лично обо мне, то я доверяю свои пароли стандартному макосовскому кейчейну. Думаю, для домохозяек он тоже сгодится.
Признаюсь, меня сильно удивило, что сейчас, накануне 2019, кто-то знает свои пароли и набирает их руками.

Они же автозаполняются? Ну хорошо, не все используют макось, но другие браузеры ведь тоже заполняют?
Скорее всего, если вы пользуетесь стандартными UI-компонентами, они буду выглядеть на семерке как надо.

А вот что будет с самонарисованными градиентами и цветами, надо посмотреть.
Сферические гранаты в вакууме.
Для разгребания результатов их работы потребуется еще больше вакансий.
Спасибо за это приложение. Перешел на него со скитча и пользуюсь постоянно.
Это тоже мое утверждение, но вы возражали на комментарий, который содержит другое.

Что касается именно этого, то я по-прежнему считаю, что плохой код — это плохая работа, но выяснится это после того, как плохой код проявит себя дополнительными затратами ресурсов, связанными с ним.
Нет, не "все дополнительные затраты — это признак плохого кода".

Возможно, существуют допзатраты, которые порождены другими причинами, я не знаю всех причин.

Я утверждаю, что плохая работа — это причина дополнительных затрат, но я нигде не говорил, что всех.
Вы сейчас возражаете против утверждения «все дополнительные затраты служат признаком плохой работы».

Напомню, что мое утверждение «плохая работа приводит к дополнительным затратам».

Эти два утверждения — не одно и то же.
Ваша модель показывает вред дополнительных затрат на подготовку к неожиданностям, которые могут и не произойти. Это плохая, ненужная работа.

Но дополнительные затраты по прежнему фигурируют и плохую работу определить помогают.
Я рад, что не зря потратил время и вы приняли мое определение плохой работы — она вызывает дополнительные затраты.

Именно это и есть объективный критерий ее определения.
Смотрите: затраты труда на превращение плоской книги в древовидную — q. Если вы тратите не q, а q+d, то вы что-то сделали не так.

d — допзатраты, В этот момент вы понимаете, что надо было делать по-другому. Оказалось, что эта работа была сделана плохо.
Зачем вы предлагаете обсуждать связь между плохой работой и удовлетворенностью заказчика?

Вы ведь возражаете против показателя дополнительных затрат, как признака плохой работы.

Я прошу вас быть точнее, если вы действительно хотите показать логические недостатки этого утверждения, а не просто спорите ради спора.
Оплата хостинга и проч. не связана с существованием вашего кода, это не дополнительные затраты на вашу работу.

Если же вам заказали не код сайта, а просто чтобы сайт был и работал, а вы не оговорили заранее затраты на хостинг, то вы действительно плохо поработали с клиентом.

Ни один из этих вариантов моему определению не противоречит.

Information

Rating
Does not participate
Location
Винница, Винницкая обл., Украина
Date of birth
Registered
Activity