Request #35448
From:
Account Type:
Free Account
Dreamwidth:
Account Name: ![[personal profile]](https://www.dreamwidth.org/img/silk/identity/user.png)
cat_mucius
cat_mucius
Email confirmed?
Yes
data version: 10
scheme:
tropo-red
Support category:
Time posted:
Mon, 26 Dec 2016 19:11:26 GMT (455 weeks ago)
Status:
closed (2 points to jennifer)
jennifer)
Summary:
Allow URLs with dreamwidth.org hostname only
Original Request:
Good day,
Currently if DreamWidth receives request for some journal in form https://dreamwidth.org/~account or https://dreamwidth.org/users/account, it automatically redirects browser to https://account.dreamwidth.org URL. It looks more pretty, but it allows potential inspectors of traffic between clients and DW to see, which specific journal was reached (by DNS query, as well as by plaintext SNI field in SSL handshake) - and block the request.
But if the URLs were remaining with only dreamwidth.org in the hostname field, then any inspection system would just see that DW was accessed - without knowing any specifics.
Today, many people migrate from LiveJournal to DW because of fear their journals would be blocked by Russian government (which actually happened). It would be nice if DW gave users tools to exclude possibility of such journal-level blocking by government agencies.
What I suggest is: if original request was for account.dreamwidth.org URL, let it stay. But if it was for https://dreamwidth.org/users/account URL or similar - don't redirect the client to "vanity URL", let it stay in this form.
And, of course, redirecting users from HTTP to HTTPS would be great.
Diagnostics: Mozilla/5.0 (Windows NT 6.1; WOW64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/55.0.2883.87 Safari/537.36
Currently if DreamWidth receives request for some journal in form https://dreamwidth.org/~account or https://dreamwidth.org/users/account, it automatically redirects browser to https://account.dreamwidth.org URL. It looks more pretty, but it allows potential inspectors of traffic between clients and DW to see, which specific journal was reached (by DNS query, as well as by plaintext SNI field in SSL handshake) - and block the request.
But if the URLs were remaining with only dreamwidth.org in the hostname field, then any inspection system would just see that DW was accessed - without knowing any specifics.
Today, many people migrate from LiveJournal to DW because of fear their journals would be blocked by Russian government (which actually happened). It would be nice if DW gave users tools to exclude possibility of such journal-level blocking by government agencies.
What I suggest is: if original request was for account.dreamwidth.org URL, let it stay. But if it was for https://dreamwidth.org/users/account URL or similar - don't redirect the client to "vanity URL", let it stay in this form.
And, of course, redirecting users from HTTP to HTTPS would be great.
Diagnostics: Mozilla/5.0 (Windows NT 6.1; WOW64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/55.0.2883.87 Safari/537.36
Hi cat_mucius,
I understand and respect your privacy concerns - however, our site setup has long required that we use a separate subdomain for each journal, and this is unlikely to change in the future. If you wish to disguise your browsing habits, the best solution I know of is to use a VPN to fully encrypt your traffic.
As for redirecting HTTP to HTTPS, we do plan to make that happen at some point. For now, if you visit the site using HTTPS, all the browser links should update to use HTTPS as well.
Please let us know if you have any other questions or concerns.
Best,
--Jen
I understand and respect your privacy concerns - however, our site setup has long required that we use a separate subdomain for each journal, and this is unlikely to change in the future. If you wish to disguise your browsing habits, the best solution I know of is to use a VPN to fully encrypt your traffic.
As for redirecting HTTP to HTTPS, we do plan to make that happen at some point. For now, if you visit the site using HTTPS, all the browser links should update to use HTTPS as well.
Please let us know if you have any other questions or concerns.
Best,
--Jen
Hi Jennifer, thanks for quick response.
Yes, I see myself that my proposed measure, to be useful, requires modification of all links inside HTML pages, mails, etc. - which is just too much work to prevent possibility of blocking and contradicts other requirements.
Thanks for your time, please feel free to mark this ticket as closed.
>> As for redirecting HTTP to HTTPS, we do plan to make that happen at some point.
Looking ahead. :-)
Yes, I see myself that my proposed measure, to be useful, requires modification of all links inside HTML pages, mails, etc. - which is just too much work to prevent possibility of blocking and contradicts other requirements.
Thanks for your time, please feel free to mark this ticket as closed.
>> As for redirecting HTTP to HTTPS, we do plan to make that happen at some point.
Looking ahead. :-)
Go to: previous open request, next open request
Return to the list of open requests.
Back to the Support Area.