Верно ли, что "использование ИИ подразумевается"?

[Alex-Yu]

lel0lel в сообщении #1730461 писал(а):

воспринимаются несколько настороженно теми, кто и до их появления успешно справлялся с задачами?

Все же основная моя мысль другая: не со всем задачами вообще нужно справляться. А если и справляться, то не любым способом, справиться с задачей -- не самоцель. Во всяком случае не безусловная цель.

-- добавлено через 46 секунд --

mihaild в сообщении #1730464 писал(а):

Право есть (я не предлагаю Вас за это банить). Но у меня есть право заметить, что Ваша позиция, если её применять последовательно, приводит к странным выводам.

Ну видите как уютно все получается

-- добавлено через 1 минуту --

mihaild в сообщении #1730464 писал(а):

Вы браузер сами написали?

Пф-ф-ф-... браузер написать... Не писал, но мог бы.

[Mental]

Вообще-то господа у вас немного дикий подход к тестированию. Существует огромное количество готовых для этого фреймворков Cypress, Pytest и т.п.
Если вы к примеру, пишите серьёзный веб-проект, то по стандарту обязаны покрыть код модульными, функциональными и E2E тестами.

[Dedekind]

(Оффтоп)

Alex-Yu in post #1730465 писал(а):

Пф-ф-ф-... браузер написать... Не писал, но мог бы.

Сдается мне, джентльмены, это была комедия просто обычный троллинг:) Хотя, наверное, это еще на этапе компьютера из песка было понятно.

[Alex-Yu]

Mental в сообщении #1730466 писал(а):

немного дикий подход к тестированию.

Любит же народ всякие второстепенные частности, имеющие лишь иллюстративное значение....

[Geen]

epros в сообщении #1730459 писал(а):

это в принципе можно было бы написать и руками

Нет, руками такое написать нельзя...

[epros]

Geen в сообщении #1730469 писал(а):

Нет, руками такое написать нельзя...

Почему? Что там такого страшного?

[mihaild]

Alex-Yu в сообщении #1730465 писал(а):

Ну видите как уютно все получается

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

Alex-Yu в сообщении #1730465 писал(а):

браузер написать... Не писал, но мог бы

А Вы хорошо себе представляете, какую мешанину непонятно чего представляют из себя HTML+CSS+JS? А браузер это всё должен рендерить, и быстро.

Mental в сообщении #1730466 писал(а):

Существует огромное количество готовых для этого фреймворков Cypress, Pytest и т.п.

Вроде бы с этим никто и не спорил.
(ну и да, я не думаю, что epros писал тесты для своей страницы; максимум они могли быть сгенерированы, но тогда мы возвращаемся к исходому вопросу)

epros в сообщении #1730459 писал(а):

(можете потестировать)

У вас там при вставке на форум скобки и апострофы побились (как минимум).

epros в сообщении #1730459 писал(а):

Рендеринг списка БЕЗ дублирующих кнопок "Добавить"

Вот это кстати частая беда - при итерациях модели очень любят оставлять следы предыдущих неудачных попыток ("а вот тут поправили"), которые совершенно не нужны.

[Mental]

(Проверка не пройдена - ChatGPT)

epros в сообщении #1730459 писал(а):

Это совсем не "машинные коды", поэтому это в принципе можно было бы написать и руками. Но всё же оцените, что проще: написать самому или просто протестировать и убедиться, что работает. Я ни одной буквы руками не правил.

Критичные риски
Шифрование не защищает от подмены самого HTML-файла.
Данные зашифрованы, но код приложения лежит рядом с ними в том же файле. Если злоумышленник изменит HTML/JS, он может просто перехватить мастер-пароль при вводе или украсть расшифрованные записи после unlock().

Секреты хранятся в глобальных JS-переменных и DOM.
currentMasterPassword и decryptedEntries доступны любому скрипту на странице. После разблокировки пароли также попадают в input value="...", то есть находятся прямо в DOM.

Есть риск XSS/опасных ссылок через поле URL.
entry.url вставляется в href после HTML-экранирования, но схема URL не проверяется. Нужно запрещать всё кроме https:/http: или хотя бы https:. Иначе сохранённая/подменённая запись с javascript: или нестандартной схемой может стать точкой атаки.

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

[mihaild]

(Оффтоп)

Mental в сообщении #1730473 писал(а):

Обычно когда такое пишется, лучше сразу прогонять на безопасность желательно в другой LLM

Для любой нетривиальной модели рисков такое лучше самостоятельно вообще не писать.
В каком-то курсе по криптографии в первом тесте был вопрос "Будете ли Вы использовать знания из этого курса для создания системы, работающей с реальными данными?", с правильным ответом "нет".

[epros]

mihaild в сообщении #1730472 писал(а):

У вас там при вставке на форум скобки и апострофы побились (как минимум).

Увы, файл выложить движок форума не даёт.

mihaild в сообщении #1730472 писал(а):

Вот это кстати частая беда - при итерациях модели очень любят оставлять следы предыдущих неудачных попыток ("а вот тут поправили"), которые совершенно не нужны.

Да, я и не подумал из кода что-то вычищать.

[dsge]

Mikhail_K в сообщении #1730426 писал(а):

Вероятно, эти журналы недостаточно солидные, не Q1

Солидность не измеряется в Q. Среди Q1 мусора достаточно.

[Geen]

Mental в сообщении #1730473 писал(а):

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

Для такого "анализа" LLM и не нужна.

[epros]

Mental в сообщении #1730473 писал(а):

Критичные риски
Шифрование не защищает от подмены самого HTML-файла.
Данные зашифрованы, но код приложения лежит рядом с ними в том же файле. Если злоумышленник изменит HTML/JS, он может просто перехватить мастер-пароль при вводе или украсть расшифрованные записи после unlock().

Секреты хранятся в глобальных JS-переменных и DOM.
currentMasterPassword и decryptedEntries доступны любому скрипту на странице. После разблокировки пароли также попадают в input value="...", то есть находятся прямо в DOM.

Есть риск XSS/опасных ссылок через поле URL.
entry.url вставляется в href после HTML-экранирования, но схема URL не проверяется. Нужно запрещать всё кроме https:/http: или хотя бы https:. Иначе сохранённая/подменённая запись с javascript: или нестандартной схемой может стать точкой атаки.

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

О, это хорошо, что Вы не только разработчика, но и тестировщика хотите заменить на ИИ. Но я вижу, что он с данной ролью пока плохо справился, хотя может быть постановка задачи ему была неудачной. Поясню:
Меня эти риски совершенно не беспокоят. Моей задачей было сохранить сами пароли от кражи, но в доступном мне месте. Подмена кода? А кто его будет менять? Это файл, который после заполнения я буду хранить у себя и уж постараюсь, чтобы коды в нём никто не менял. После расшифровки данные доступны для чего-то там? Ха, а ещё они показываются прямо на экране и злоумышленник мог бы подсмотреть их, заглянув мне через плечо. Просто не расшифровывайте свои пароли на глазах у злоумышленников.

[Mental]

Geen в сообщении #1730478 писал(а):

Для такого "анализа" LLM и не нужна.

В данном конкретном примере возможно и да. Ошибки безопасности стандартные.
Но в общих случаях делают именно так.
Это называется схема перекрестной проверки кода (LLM Peer Review), с помощью которой повышают его надежность. Первая модель пишет код по ТЗ, а вторая (другого семейства) проводит аудит на баги, уязвимости и соответствие стандартам

[Geen]

epros в сообщении #1730479 писал(а):

А кто его будет менять?

А от кого прячем?