Hello,
Danbooru currently doesn't force all connections to be encrypted. Lots of people keep sending me plain http links because of this which is a huge privacy issue.
Please set a HSTS header to protect the users privacy.
Posted under Bugs & Features
dwodmots said:
Hello,
Danbooru currently doesn't force all connections to be encrypted. Lots of people keep sending me plain http links because of this which is a huge privacy issue.
Please set a HSTS header to protect the users privacy.
Personally, I don't use https because it breaks the tag auto-complete.
CodeKyuubi said:
Personally, I don't use https because it breaks the tag auto-complete.
It does not.
dwodmots said:
Hello,
Danbooru currently doesn't force all connections to be encrypted. Lots of people keep sending me plain http links because of this which is a huge privacy issue.
Please set a HSTS header to protect the users privacy.
Why? If someone doesn't have ability to load the site because their network blocks SSL or their certs are out of date this will prevent them from accessing the site. Also you can add a rule to your browser's security settings by yourself or use EFF's HTTPS Everywhere browser extensions.
chinatsu said:
It does not.
Why? If someone doesn't have ability to load the site because their network blocks SSL or their certs are out of date this will prevent them from accessing the site. Also you can add a rule to your browser's security settings by yourself or use EFF's HTTPS Everywhere browser extensions.
Tell that to my computers, because it most definitely does.
I use DanbooruUp chrome extension for tag completion.
CodeKyuubi said:
Tell that to my computers, because it most definitely does.
I use DanbooruUp chrome extension for tag completion.
Yeah, talk to your computers. You should run the site with addons disabled before saying it doesn't work.
Your addon is unmaintained. You can extract the crx file and add the HTTPS URLs to the manifest.json and inject.js.
chinatsu said:
Yeah, talk to your computers. You should run the site with addons disabled before saying it doesn't work.
Your addon is unmaintained. You can extract the crx file and add the HTTPS URLs to the manifest.json and inject.js.
That honestly sounds like rocket science to me. I don't know fancy things like programming, I just rely on others to make tools and write the instructions to use said tools.
I'm against HSTS. I used to run into all sorts of problems with sites using it, back when I was forced to use a restricted network access and older software. The problem with HSTS is that it disallows access through HTTP for browsers, so any time you can't access through https (because, say, port 443 is blocked, or you're using something like java 6 which has a buggy HTTPS client), you can't access the site at all. If you want security, take care about it yourself using the addon; danbooru provides the necessary prerequisites for it to work.
CodeKyuubi said:
That honestly sounds like rocket science to me. I don't know fancy things like programming, I just rely on others to make tools and write the instructions to use said tools.
Then use the one in topic #14701 which works much better, don't just complain about the site when the fault is on your deprecated tools.
nonamethanks said:
Then use the one in topic #14701 which works much better, don't just complain about the site when the fault is on your deprecated tools.
Does it fix how slow Danbooru's built-in completion was? I remember I tried using it for a few weeks but it would sometimes take up to 15-20 seconds for the list to show.
CodeKyuubi said:
Does it fix how slow Danbooru's built-in completion was? I remember I tried using it for a few weeks but it would sometimes take up to 15-20 seconds for the list to show.
This is getting off-topic, but from my own observations using Chrome and Firefox, the average time autocomplete takes when it's making a network call is a quarter of a second. After that it caches those results locally so that it takes almost no time at all the next time you type using the same terms. If you were experiencing 15-20 seconds, then you were trying it out in the period when Danbooru was exceptionally slow. You should try it out when Danbooru isn't being so slow. The plain vanilla Autocomplete that Danbooru provides works pretty good.
Getting back on-topic, I agree with Type-kun here. I don't think Danbooru should force users to use HTTPS if they don't want to. Certain conditions may prevent them from doing so, which would block their access to the site. Regardless of that, I prefer to use HTTP whenever possible. Not everything needs to be secured IMO, and I could care less if someone can read my network traffic.
Facebook, Google, Youtube, Reddit, Pixiv, and Twitter already enable HSTS. HTTPS is becoming the norm. If you can't use HTTPS, then I'm sorry, but you're screwed already.
Browsers are increasingly pushing HTTPS too. Right now in Chrome a "Not secure" warning comes up next to the address bar whenever you submit any data to the site, including searches. Eventually Chrome is going to show "Not secure" warnings by default for all HTTP sites.
I don't agree with making security decisions to accommodate hostile networks. Given that Danbooru hosts sensitive content - sensitive enough that Danbooru is banned in multiple countries - it's not very advisable to use Danbooru unencrypted on such a network. That's exactly the situation where you should be extra careful about someone monitoring your browsing activity.
It's not just browsing privacy either. If you login over HTTP your password will be sent in the clear. If you check the "Remember" option while signing in, your password hash will be saved in a cookie, which will also be sent in the clear on every request. Your password can potentially be cracked and stolen in this way.
Before you say "who cares if my Danbooru password gets stolen?", remember that a) many people reuse passwords across sites, and b) if a Mod+ account gets hacked, it matters to all of us. Security is not something users can or should be expected to take care of themselves.
It's really all about risk management. Sure using HTTP isn't secure, and sure it would be an issue if a malicious actor were to get a moderators credentials. But the probability of such events are very low. The actors that could actually accomplish those feats are not going to be targeting Danbooru. They are going after much juicier and higher-value assets. Since the probability is very low, even though the potential for damage is moderate-high, the overall risk is low.
Even if the risk is low, why risk it anyway if the alternative is pretty easy?
Leaving security to the user is always the wrong choice because most couldn’t care less about it. That also means that they won’t care about being forced into HTTPS either. Allowing HTTP for outdated software is wrong because it’s the outdated software that needs to be fixed. And certain networks not allowing HTTPS connections is a pretty doubtful argument to me because with all those big sites (Google, Twitter, Facebook, etc) forcing HTTPS, not being able to access Danbooru should be one of your least concerns.
kittey said:
Even if the risk is low, why risk it anyway if the alternative is pretty easy?
Easy? Maybe... I don't know how much work would be involved. Without cost... absolutely not!
I just ran a little experiment on my client where I hit the posts controller a thousand times each for both HTTP and HTTPS using just the API, so there wasn't even any page loading involved, and the numbers weren't good for HTTPS. No matter how I tested them, either at the same time or separately, HTTP performed on average at least 2 times faster than HTTPS.
Average connection time:
In the spirit of fairness, I used session-tracking on HTML and repeated the above, which should allow HTTPS to perform better.
Average connection time:
So HTTPS does perform better when sessions are involved, but not everything can or does make use of them.
Finally, a real world example using my autocomplete script from topic #14701, which uses the same function calls as Danbooru's autocomplete.
So certain uses of the protocols perform better in some cases, however HTTP always performs better.
Now, these are just the numbers on the client-side. If Danbooru were to switch over completely to HTTPS, the situation would only be compounded. All of those connections on Danbooru's end would have to take more time handling each connection, which would make the server slower, which would make the above numbers even worse if this were to be implemented. This is just a guestimate, but I could easily see connections on average being 2 to 4 times slower than they are now for HTTP in some cases.
All of those big companies like Google and whatnot have tremendous resources to throw at the problem. Danbooru doesn't. Even if it did, there's no getting around the fact that setting up a secure connection takes longer. There is no such thing as a free lunch. I for one prefer to choose speed over privacy, although I don't begrudge those that choose the other way. Just don't force it onto the rest of us.
Even if we don’t force HSTS (for now?), there are a few things that would increase security without forcing everyone into something.
As Evazion sounded pretty pro-security, I’m hoping that he’d be interested in implementing something like that. :)
These things being said, I would like to suggest this compromise:
evazion said:
...
- Add a http://insecure.donmai.us domain that doesn't use HSTS. If you really need to use HTTP, then you can opt-in to it explicitly by using this domain.
i'm seriously considering http://unsafebooru.donmai.us should be used instead =D