4 ms·

Looks like the post got updated with some reasoning: > Why can’t we put a read-only archive online currently? The Wiki, even in it’s read-only state, was pres

Looks like the post got updated with some reasoning: > Why can’t we put a read-only archive online currently? The Wiki, even in it’s read-only state, was presenting security risks, and it was deemed necessary to take it offline.

smacktoward 7y ago
So crawl the Wiki pages, grind out static HTML copies of them, and make those available. Not many security risks associated with static HTML. What am I missing here?
- nitemice 7y ago
  The only other "security risk" I can imagine such a read-only wiki could present is if it documents something that could be considered "risky" from a security perspective. That would make this more of a censorship situation.
  - moonchild 7y ago
    > We still have the data, and as mentioned above, we will work to migrate the top content into various official resources. In the meantime, we’re investigating how we can make this content available, even in a rudimentary way. This indicates otherwise.
- Ndymium 7y ago
  I did this for a forum I used to host for many years. I crawled versions for people (using a user with the same rights as they did so it wouldn't contain anything extra) with static assets and referred images and zipped that up, so they could browse the old posts locally and nostalgize. It worked really well. Maybe the people at UE need to be taught how to use wget.
- onion2k 7y ago
  Static content needs a web server and a way to move the content to the server (ftp, sftp, rsync..), and ssl certification, and a DNS entry, and DDOS protection, and a way to manage credentials for those things. It's not zero risk at all. There are plenty of ways to attack a static site. The only way static is safer is because you're not executing scripts on the server (which is a massive win, I don't want to down play that aspect), everything else is the same as a dynamic site. That's still a lame excuse though. They could have outsourced all the "hard" stuff to a free Netlify account.
  - mekster 7y ago
    Like what problem specifically that you cannot mitigate? If you can't just host static contents on a new empty server and get it going, how does the rest of the world work at all? That is just an excuse.
- conistonwater 7y ago
  I read it's very easy to that nowadays with Chrome's Puppeteer.
  - lstamour 7y ago
    Easier still with wget perhaps? https://www.gnu.org/software/wget/manual/wget.html#Very-Advanced-Usage https://www.gnu.org/software/wget/manual/wget.html#Very-Adva...
Kiro 7y ago
How can it be a security risk?
nikanj 7y ago
Turn both the DB and the disk read-only and your security issues should mostly be solved.

smacktoward 7y ago

So crawl the Wiki pages, grind out static HTML copies of them, and make those available. Not many security risks associated with static HTML. What am I missing here?

nitemice 7y ago
The only other "security risk" I can imagine such a read-only wiki could present is if it documents something that could be considered "risky" from a security perspective. That would make this more of a censorship situation.
- moonchild 7y ago
  > We still have the data, and as mentioned above, we will work to migrate the top content into various official resources. In the meantime, we’re investigating how we can make this content available, even in a rudimentary way. This indicates otherwise.
Ndymium 7y ago
I did this for a forum I used to host for many years. I crawled versions for people (using a user with the same rights as they did so it wouldn't contain anything extra) with static assets and referred images and zipped that up, so they could browse the old posts locally and nostalgize. It worked really well. Maybe the people at UE need to be taught how to use wget.
onion2k 7y ago
Static content needs a web server and a way to move the content to the server (ftp, sftp, rsync..), and ssl certification, and a DNS entry, and DDOS protection, and a way to manage credentials for those things. It's not zero risk at all. There are plenty of ways to attack a static site. The only way static is safer is because you're not executing scripts on the server (which is a massive win, I don't want to down play that aspect), everything else is the same as a dynamic site. That's still a lame excuse though. They could have outsourced all the "hard" stuff to a free Netlify account.
- mekster 7y ago
  Like what problem specifically that you cannot mitigate? If you can't just host static contents on a new empty server and get it going, how does the rest of the world work at all? That is just an excuse.
conistonwater 7y ago
I read it's very easy to that nowadays with Chrome's Puppeteer.
- lstamour 7y ago
  Easier still with wget perhaps? https://www.gnu.org/software/wget/manual/wget.html#Very-Advanced-Usage https://www.gnu.org/software/wget/manual/wget.html#Very-Adva...

Kiro 7y ago

How can it be a security risk?

nikanj 7y ago

Turn both the DB and the disk read-only and your security issues should mostly be solved.