Ипатьев

Ну по кукам вот гуглится https://superuser.com/a/920604
Лежат в sqlite3

• on Linux: ~/.config/google-chrome/Default/Cookies
  
• on Windows: %LOCALAPPDATA%\Google\Chrome\User Data\Default\Cookies
  
• on Mac: ~/Library/Application Support/Google/Chrome/Default/Cookies
  

Правда, сам файлик БД пришлось поискать, он у меня оказался в ещё одной папке Network
Запросом

DELETE FROM cookies where host_key LIKE '%habr.com'

у меня получилось разлогиниться с Хабра. Только предварительно надо было закрыть браузер.

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

На английском есть специализированный сайт codereview@stackexchange, при наличии языка это идеальный вариант.

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

Самый надёжный способ получить code-review, это завести два аккаунта. С одного задать вопрос, "как сделать то-то", а с другого - запостить код, который это делает. И тут же набегут советчики, рассказать, что в этом коде неправильно.

Делать запрос не напрямую из js, а обращаться к php скрипту на сервере. В РНР делать запрос курлом и возвращать ответ обратно в js.
Примеров что в сети, что конкретно на этом сайте - миллионы. Вот свежий
Если не знаете РНР и не готовы учиться, то за готовым кодом на https://freelance.habr.com/

Дело не в размере данных, а в их структуре.
Если хранить данные в виде json, то запросы действительно начнут тупить очень быстро.
Если создать нормальную структуру и записывать каждый элемент данных в свою ячейку, а json использовать только в исключительных случаях, для заведомо неструктурируемой информации, то даже при объемах в сто раз больше всё будет летать.

Делаем загадочные движения руками, незаметно меняем тег br на td и... Магия!

foreach($row as $v) {
    echo "<td>$v</td>";
}

Но на самом деле обычно так не делают, и действительно вытаскивают "что-то одно". Попутно разделяя работу с SQL и HTML и защищаясь от инъекцй. Для этого:

• сначала получаем нужные на странице данные. Если выводим список, то записываем его в массив
  
• только после того как все данные получены и обработаны, можно начинать вывод. В простейшем варианте закрываем тег РНР и начинаем выводить HTML и в нужных местах - запрошенные выше данные
  
• не забывая их в обязательном порядке экранировать
  
  

$data = $mysqli->query('SELECT * FROM users')->fetch_all(MYSQLI_ASSOC);
?>
<table>
  <?php foreach($data as $row): ?>
    <tr>
        <td><?=htmlspecialchars($row['id'], ENT_QUOTES) ?></td>
        <td><?=htmlspecialchars($row['name'], ENT_QUOTES) ?></td>
        <td><?=htmlspecialchars($row['email'], ENT_QUOTES) ?></td>
    </tr>
  <?php endforeach ?>
</table>

Здесь два вопроса в одном, как прочитать файл, и как назначить в переменные.
Судя по формулировке, вы не знаете даже как прочитать файл,поэтому надо начать с этого.
Самый простой и наглядный способ - это просто читать каждую строку и добавлять в список.

config = [];
with open(filename) as file:
    for line in file:
        config.append(line.rstrip());

Теперь можно назначить отдельным переменным, например
email=config[0]
Но я бы не стал назначать отдельным переменным, а подумал над более удобным механизмом. Например, добавил бы все значения не в список, а в словарь

Да

Какой-то странный ответ выбран решением.
По количеству "фич" SQLite может поспорить со многими "настоящими" базами данных. Я уверен, что автор этого заявления не знает и 5% фич что Sqlite, что Postgres, что mysql.
Непонятно, за счёт чего "Postgresql конечно будет сложнее". Запросы практически те же самые, код тоже особо не изменится. Понятно, что надо будет собственно установить постгрес или там mysql, но это разовое действие, а сама работа с Postgresql ничуть не сложнее чем с sqlite.

Главное отличие sqlite от "нормальных" баз данных не в какой-то воображаемой "простоте", а в том что она встроенная. То есть запускается вместе со скриптом, и вместе с ним же умирает. И памяти ей доступно ровно столько, сколько скрипту. Из чего следует, что индексы, хотя и могут помочь, но их приходится заново считывать в память при каждом запуске скрипта.

В то время как классические DBMS являются постоянно висящими в памяти демонами. У которых все индексы, соответственно, тоже висят в памяти. То есть при обработке запроса система может не сделать вообще ни одного обращения к диску. За счет чего достигается огромный прирост производительности. Надо только следить за тем, чтобы хватало памяти, выделенной для индексов.

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