dw_suggestions | Entries tagged with site: privacy

Title:
Unscreen your comments from Post Comment Success page

Area:
entry comments

Summary:
Dreamwidth screened comment settings currently entail screening our own comments when we choose to screen all comments on our journals (I'm not sure if this behavior is the same for communities). I'd like to suggest we save time for journal owners, specifically, by allowing them to unscreen their own comments from the Post Comment Success page.

Description:
Dreamwidth screened comment settings currently entail screening our own comments when we choose to screen all comments on our journals (I'm not sure if this behavior is the same for communities). I'd like to suggest we save time for journal owners, specifically, by allowing them to unscreen their own comments from the Post Comment Success page (https://www.dreamwidth.org/talkpost_do). This saves time - no more going back to the entry or your DW Inbox or off-site email to find and unscreen the comment you just ~~replied~~ made in reply to someone.

Poll #18202 Unscreen your comments from Post Comment Success page

Open to: Registered Users, detailed results viewable to: All, participants: 34

View Respondents

This suggestion:

View Answers

Should be implemented as-is.
18 (52.9%)

Should be implemented with changes. (please comment)
0 (0.0%)

Shouldn't be implemented.
0 (0.0%)

(I have no opinion)
16 (47.1%)

(Other: please comment)
0 (0.0%)

marahmarie

Title:
Show poster is banned from quickreply

Area:
quickreply

Summary:
In quickreply there is nothing stating a user's ban status. If a user types a comment in a journal or community from which they have been (perhaps unknowingly) banned, if they use quickreply to do so they won't realize (or recall, if they've forgotten) their ban status until they try to post their comment or else if they click through to the "more options" full-size comment box before posting.

Description:
Quickreply (the instant comment box you get on the reading page under each entry if you click "reply" from the entry linkbar) doesn't currently show relationship status to other users or communities. While kludging in the entire relationship status functionality might be a bit much for a simple reply box, it would be helpful to know if you're wasting your time writing the Gettysburg address in reply to someone, only to realize at the last second, when you try to post, that you've been banned from the journal or community in question.

While I'm not sure how it might be done, my thought is to make ban status (if applicable) visible so it can be seen before you try to post from a quickreply box. While I don't see a lot of room for it as I look at a quickreply box as I type this up, I'm thinking in addition to* the JS usericon-picker saying "Browse" in big, bold letters when you hover over it, it could say "You have been banned from this community/journal" as well.

*An earlier version of this said "While I don't see a lot of room for it as I look at a quickreply box as I type this up, I'm thinking instead of the JS usericon-picker saying "Browse" in big, bold letters when you hover over it, it could say "You have been banned from this community/journal" instead", then I realized, after posting, that "in addition to" would be better than "instead of".

Poll #18125 Show poster is banned from quickreply

Open to: Registered Users, detailed results viewable to: All, participants: 34

View Respondents

This suggestion:

View Answers

Should be implemented as-is.
16 (47.1%)

Should be implemented with changes. (please comment)
3 (8.8%)

Shouldn't be implemented.
0 (0.0%)

(I have no opinion)
13 (38.2%)

(Other: please comment)
2 (5.9%)

technoshaman

Title:
Suppress content in inbox notification

Area:
Inbox

Summary:
Make it toggleable as to whether the *content* of a private inbox message is sent in email. Currently the whole message comes with the notification, instead of just saying "you have a message".

Description:
DW is known for its superior privacy features. One thing it *doesn't* have - yet - is truly secure messaging, i.e. the only thing that goes outside DW is "you have a message". However, some people like using email as a vehicle for interacting with their social media. So I think in our privacy settings we should have a radio button: "Send content of messages with notification: yes/no" We could do this for comments, too, as a 2.0 thing. You could go one step further and make the "from whom" part togggleable too. Some messages are more sensitive than others... f'rex, the fact that I got a message from, oh, say, Bernie Sanders or Coretta Scott King or Dan Rather would be far more sensitive than getting a message from Joe Random I went to school with who didn't amount to much. I don't think we should go down as far as per-user.... that's a little much, and if you're that level of paranoid you should probably just turn off the "who" altogether.... but still. Having "you've got mail" land in your Gmail or Yahoo inbox where g-ds know who can see it is a lot safer than "meet me outside the palace at 2am with the gunpowder! Cheers, Guy"...

Poll #18046 Suppress content in inbox notification

Open to: Registered Users, detailed results viewable to: All, participants: 35

View Respondents

This suggestion:

View Answers

Should be implemented as-is.
15 (42.9%)

Should be implemented with changes. (please comment)
0 (0.0%)

Shouldn't be implemented.
4 (11.4%)

(I have no opinion)
15 (42.9%)

(Other: please comment)
1 (2.9%)

julysnowed

Title:
Reconsidering the Ability to Delete All Entries/Comments Associated With an Account Upon Deletion

Area:
accounts, entries, comments

Summary:
With the dramatic increase in recent years in both online and real-world harassment, I would like to consider revisiting the 2010 suggestion to give users the option to delete all entries/comments associated with an account upon account deletion.

Description:
The last time this suggestion was raised was in 2010, and it was rejected then. However, I think it's long past time to revisit the possibility of being able to delete all entries and comments associated with an account upon account deletion.

There are a lot of reasons people delete accounts. Sometimes those reasons are just a lack of time or interest, and that's okay. But sometimes those reasons get a lot more serious. We over-share sometimes. The people we meet online become friends, and we get lax about sharing personal information that perhaps shouldn't be shared in public internet spaces. Most of the time that never becomes a problem--most of the people we meet online are great. But sometimes the people who have access to your entries/posts/comments aren't great, and that can have repercussions irl just as easily as it can have repercussions online. The last few years have seen a dramatic uptick in everything from revenge porn to death threats to hacked accounts, and while stalking and real-world harassment are rare, they happen, and they're happening with increasing frequency. They happen often enough that (as of the time of this writing) a tumblr post about tips for how to disappear from the internet has over 760,000 notes.

Right now, Dreamwidth allows its users to delete comments manually, and to see the last 100/150 comments posted on paid/premium accounts, but many of us have posted thousands of comments over several years, and trying to find every single comment and offhand remark ever posted is an endeavor that's anxiety-inducing at best and impossible at worst. Giving users an option to automatically delete every post/comment they've ever made, even those made on outside communities or journals, would alleviate that burden entirely.

The biggest concern with this suggestion-and the concern that I saw raised most often on the 2010 post--was that it would inevitably leave conversations broken. There are ways to mitigate that: a suggestion I saw raised in the 2010 post was to add an "orphan all comments" feature in addition to a "delete all comments" feature. AO3 currently has a popular analogous option for those who want to remove their association with their fanworks without deleting them entirely. A quick review of several LiveJournal posts will also show that broken threads are in the minority, so we may not have to worry about that too much. Even if they weren't in the minority, though, it would still be a necessary evil; our conversations are important, but I don't feel that they should be more important than the safety of our users.

Poll #18021 Reconsidering the Ability to Delete All Entries/Comments Associated With an Account Upon Deletion

Open to: Registered Users, detailed results viewable to: All, participants: 48

View Respondents

This suggestion:

View Answers

Should be implemented as-is.
15 (31.2%)

Should be implemented with changes. (please comment)
10 (20.8%)

Shouldn't be implemented.
13 (27.1%)

(I have no opinion)
9 (18.8%)

(Other: please comment)
1 (2.1%)

pseudomonas

Title:
In Case of Emergency write-only access

Area:
Posting

Summary:
Give limited access to a small number of other DW users to make posts on your behalf, with restrictions. [New feature suggestion]

Description:
What I want is a write-only function where (say) I nominate (say) you as an In-Case-of-Emergency poster for if I'm (say) ill in hospital; you can then post to my DW, but without any ability to see locked entries, modify settings, modify circle, or anything else; furthermore there'd be a prominent heading applied to any posts you made saying "posted by [YOURUSERNAMEHERE]", so impersonation wouldn't be possible. I can always delete or modify the posts that you have made on my behalf. Crossposting would work as normal.

Other methods:
a) implement this as an external website, using OpenID to verify you and store my password. Requires competently-run, secure, trustworthy third-party site. Need to remember to log in to that site every time I change my DW password.

b) give you my password. Trusts you to keep it safe, not lose it, and I have to tell you every time I change it. Allows impersonation and account-modification.

c) Give you my post-by-mail credentials. As above, but doesn't allow impersonation, eats an address slot per person, and only works for paid/permanent users.

d) The one that usually gets done these days - you making unlocked posts and hoping that enough of my circle see the post and that I don't have anyone I'd rather didn't know. This has the advantage of being simple, but is really not an effective solution to the problem.

Considerations:
I would favour the poster having the ability to post using any publicly-visible security setting that would let the poster see the post (at least "access-list-only" or "public") and possibly edit posts that they have themselves made (but not remove the header saying that the post was made by them). I don't see much need for anything beyond that; they can comment on posts as themselves.

I would envision small number of people given these posting privileges, though I don't have a particular limit in mind, and I don't see a really good reason to put a hard-limit on things.

There's always a risk that someone will post a malicious or spurious report, but really they can do that *anyway* via method d), it's called lying, and it's a social problem that is solved by only authorizing people that you trust not to do that kind of thing.

Poll #15788 In Case of Emergency write-only access

Open to: Registered Users, detailed results viewable to: All, participants: 61

View Respondents

This suggestion:

View Answers

Should be implemented as-is.
32 (52.5%)

Should be implemented with changes. (please comment)
15 (24.6%)

Shouldn't be implemented.
2 (3.3%)

(I have no opinion)
12 (19.7%)

(Other: please comment)
0 (0.0%)

hatman

Title:
Password protect posts so non-DW friends can be included

Area:
entries

Summary:
Add an additional security option between "public" and "friends" where the post is viewable to anyone with the correct password. This would allow users to include friends without DW accounts in non-public posts.

Description:
It's been a few years since this was last suggested ( http://dw-suggestions.dreamwidth.org/147407.html ). Maybe opinions have changed.

WordPress has a password protected post option ( http://en.support.wordpress.com/posts/post-visibility/#password-protect-a-post ). A post with this security setting is viewable to anyone with the correct password. The public and RSS readers can see that a new post is there, but you must enter the password to read the actual content. This allows you to have non-public content available to friends who don't have an account on the site (or who use OpenID). I'd like to see something akin to that implemented here.

A modification suggested in the comments last time would also include the option to make the post (including password prompt) viewable only by direct link.

Having it not only gives you greater control over who outside the site can see your content, it might just pull in new users. They'd come to the site to read your posts, see how it works, and maybe just be tempted to try it themselves.

So it works like this:

Between "Public" and "Access List," there would be an additional security option labeled "Password Protected." When you select that, you enter a password. When the post goes up, you have what amounts to a cut tag hiding the post's contents (including comments) until the reader enters the correct password. An additional sub-option (available via checkbox, perhaps?) would allow you to make even the password prompt viewable via direct link only. Crossposts would link back to DW, where readers would be prompted for the password.

Poll #15787 Password protect posts so non-DW friends can be included

Open to: Registered Users, detailed results viewable to: All, participants: 54

View Respondents

This suggestion:

View Answers

Should be implemented as-is.
10 (18.5%)

Should be implemented with changes. (please comment)
9 (16.7%)

Shouldn't be implemented.
23 (42.6%)

(I have no opinion)
12 (22.2%)

(Other: please comment)
0 (0.0%)

elf

Title:
Send notifications of unscreened comments in tracked threads

Area:
Commenting, tracking threads, notifications

Summary:
I'd like to get notifications of comments in screened threads, where a moderator later unscreens them. Right now, if you subscribe to a thread, you get notified of new comments--but not if they're screened. And there's no notification sent out on unscreening.

Description:
I don't know how technically difficult this would be to implement. All I know is, when I try to track threads in anon love memes, where comments are often screened until a moderator opens them, I don't get email notifications. I assume there are similar problems in some gaming journals and some kink memes--if you're not the person being replied to, you have to keep checking back to find out if there are new responses.

I assume that the "send notification" code activates immediately upon commenting, and is interrupted if the comment is screened. There may not be an easy way to implement "when comment is unscreened, check to see if anyone's subscribed, and send notification," especially if that includes "...but first, check to see if that person's already been notified, either because they were the reply-to person and got notified when the comment was made, or because the comment was originally unscreened, later screened, and is now being unscreened again."

I can't think of any drawbacks to this (other than, of course, it may be horrendously difficult to code), but I can easily believe I'm missing some. I don't know if there are any comms that make use of the lack-of-notification as it currently exists.

Poll #14084 Send notifications of unscreened comments in tracked threads

Open to: Registered Users, detailed results viewable to: All, participants: 50

View Respondents

This suggestion:

View Answers

Should be implemented as-is.
40 (80.0%)

Should be implemented with changes. (please comment)
3 (6.0%)

Shouldn't be implemented.
1 (2.0%)

(I have no opinion)
6 (12.0%)

(Other: please comment)
0 (0.0%)

icelightning

Title:
Option for Blind Polls Until Closed

Area:
Polls

Summary:
Allow an option for polls to not show their results until after they're closed.

Description:
I've noticed that seeing how voting has gone so far in a poll can affect the poll outcome. It would be wonderful if a poll could be blind to everyone, or just to everyone but the creator, until the poll closes. This would be an option and not a requirement for polls.

Basically, we've found that polls that were supposed to gage a measure of change in a character to obtain a new status ended up being nothing more than popularity polls. (Yes, it's an RPG.) Even though there are suggestions in the works to improve the poll, the suggestions I can come up with still have an element of becoming a popularity poll as people can still view current results before voting themselves. Only a truly blind poll could really alleviate this issue. I'm sure other types of communities would also use this option. The rest of the poll options would stay the same, including what results would be seen, but the results still would not be shown until the poll is closed. Basically, it'd reflect how we do voting in everyday life (elections, closed ballots, etc).

That way, polls would more closely represent individuals choices and not have their opinions influenced by others. (Also, the surprise element is fun!) It wouldn't prevent users from talking amongst themselves on whom they voted on, but it'd be closer to how voting works outside of Dreamwidth.

Poll #13463 Option for Blind Polls Until Closed

Open to: Registered Users, detailed results viewable to: All, participants: 73

View Respondents

This suggestion:

View Answers

Should be implemented as-is.
67 (91.8%)

Should be implemented with changes. (please comment)
1 (1.4%)

Shouldn't be implemented.
0 (0.0%)

(I have no opinion)
5 (6.8%)

(Other: please comment)
0 (0.0%)

montuos

Title:
Save selected icon when having to re-login to post a comment

Area:
commenting, icons

Summary:
When you get logged out while you're composing a comment so you have to re-login to post the comment, I think the comment form should save the icon you've selected (the same way your comment text is saved) instead of reverting to your default icon.

Description:
My login cookie expired/disappeared (I forget the exact wording of the error message) while I was composing a comment, so I got sent to another page to sign back in to post the comment. It was really nice that my comment text was saved, but my default icon was used instead of the other one I had selected when composing my comment.

I think it would be better if the log-back-in-to-post-your-comment page remembered the selected icon instead of reverting to the default one.

Poll #13095 Save selected icon when having to re-login to post a comment

Open to: Registered Users, detailed results viewable to: All, participants: 50

View Respondents

This suggestion:

View Answers

Should be implemented as-is.
38 (76.0%)

Should be implemented with changes. (please comment)
0 (0.0%)

Shouldn't be implemented.
0 (0.0%)

(I have no opinion)
12 (24.0%)

(Other: please comment)
0 (0.0%)

squirrelitude

Title:
"Display crosspost link" should be retroactive

Area:
Crossposting

Summary:
When "Display Crosspost Link" in Account Settings > Other Sites is checked or unchecked, it should retroactively affect all of a user's existing Dreamwidth entries.

Description:
Motivation: I only recently discovered that this option existed, and was enabled on my account. I disabled it because my DW journal is a public identity and it crossposts to a non-public LJ identity. I'd really rather not have that link show up on old entries, but I don't know how to remove it!

Expected behavior was that changing the setting would change the old entries.

Note: Editing an old DW post does not seem to change the link's existence.

Poll #12913 "Display crosspost link" should be retroactive

Open to: Registered Users, detailed results viewable to: All, participants: 50

View Respondents

This suggestion:

View Answers

Should be implemented as-is.
7 (14.0%)

Should be implemented with changes. (please comment)
15 (30.0%)

Shouldn't be implemented.
5 (10.0%)

(I have no opinion)
19 (38.0%)

(Other: please comment)
4 (8.0%)

wailor

Title:
Some privacy incoherence

Area:
Profile

Summary:
There's a way that allows people to know I have updated my journal with a filter entry (and they aren't inside that filter).

Description:
Ok so here's what I've noticed:

Imagine you have a few friends and you want to post an entry to prepared a surprised b-day party just for one of them. You don't want him or her to know about it so you'll post a filter entry right? but, if that friend is smart enough and have some curiosity, he or she could discover that I've posted a new filter entry. That's a problem because that person could feel upset about it thinking that I have something to hide to him or her.

The way he or she could discover it is by my profile page. There's some information that I can't hide that tells her or him that there's something new that she or he isn't allow to see. That information is the number of "journal entries" and the "last updated".

The example I wrote up there is just one of multiple cases where it'll be necessary to hide that information and I can't think a reason why I couldn't hide it.

So, my suggestion is to allow to hide that information as I do with other things like my birthday, my location, etc.

Poll #12623 Some privacy incoherence

Open to: Registered Users, detailed results viewable to: All, participants: 64

View Respondents

This suggestion:

View Answers

Should be implemented as-is.
11 (17.2%)

Should be implemented with changes. (please comment)
8 (12.5%)

Shouldn't be implemented.
32 (50.0%)

(I have no opinion)
11 (17.2%)

(Other: please comment)
2 (3.1%)

alexbayleaf

Title:
Notifications to detect spoofing if posting by email

Area:
email, posts

Summary:
It's possible, though unlikely, for someone to spoof posts from you by email. Notifications would help people recognise if/when this happens.

Description:
This one's a bit out there, but it came up in discussion about replying to comments by email, so I'm posting it as a suggestion.

Currently you can post by email from any of a list of registered email addresses. You also need to use a PIN to post. However, if someone knew your email address and could guess your PIN, it would be possible for them to spoof your email and post as you.

I therefore propose a notification setting: "notify me when I post by email". This should go to your primary registered address and basically just say, "We received an email post from address blah@blah.com, here's a link to it."

As well as being a warning if someone's spoofing you, it could also just be a good diagnostic to make sure your posts are getting through, if you don't have web access. Which after all could be a big part of why you're posting by email in the first place.

(You could make the setting be a bit cleverer, if you wanted to, by offering options like: "Notify me when I post by email: always, if spoofing is suspected, never". The "if spoofing is suspected" could be based on various things, but the obvious one that comes to me is <a href="http://en.wikipedia.org/wiki/Sender_Policy_Framework">SPF</a> records. But this is not a core part of the suggestion, just an idea for further work if someone were that way inclined.)

Poll #12344 Notifications to detect spoofing if posting by email

Open to: Registered Users, detailed results viewable to: All, participants: 49

View Respondents

This suggestion:

View Answers

Should be implemented as-is.
34 (69.4%)

Should be implemented with changes. (please comment)
0 (0.0%)

Shouldn't be implemented.
0 (0.0%)

(I have no opinion)
15 (30.6%)

(Other: please comment)
0 (0.0%)

alexbayleaf

Title:
Allow comments by replying to email notification

Area:
email, comments

Summary:
Use the same mechanisms used for post-by-email to allow comment-by-email. That is, comments by email should only be allowed from your registered address(es), and you should have to enter a PIN.

Description:
Currently DW allows post-by-email (http://www.dreamwidth.org/manage/emailpost) but doesn't allow you to reply to comments by email. This proposal adds commenting while avoiding some of the security problems that Livejournal (allegedly?) has with their reply-form-in-the-email solution.

Basically, we just add an option to the "mobile post settings" saying "Also allow comments by email". When commenting by email, you would have to put the PIN in the text of the comment. We could specify eg. that it should be the first line of the comment:

PIN: blahblah

A simple regexp should be able to strip PINs from comments and then check them against the user's actual PIN and make sure it's the right one.

The comment notification email should include a message to the effect of "Want to reply via email? Set it up here." (if you aren't registered for email replies) or, "To reply by email, simply reply to this message and include your PIN as described here" (with a link to the help or whatever).

Poll #12343 Allow comments by replying to email notification

Open to: Registered Users, detailed results viewable to: All, participants: 48

View Respondents

This suggestion:

View Answers

Should be implemented as-is.
28 (58.3%)

Should be implemented with changes. (please comment)
1 (2.1%)

Shouldn't be implemented.
1 (2.1%)

(I have no opinion)
17 (35.4%)

(Other: please comment)
1 (2.1%)

kaberett

Title:
"This post will self-destruct shortly...": automated security changes

Area:
privacy, filters

Summary:
People commonly make public posts which they do not wish to remain public indefinitely. An additional field at posting ("Change security [...] to [...] when [...] (has/have) elapsed") would remove the need to remember to make the manual change at a later date.

Description:
I repeatedly come across cases where people make a post with the specific intention of subsequently changing its visibility, for example:

(1) person with username A changes it to B. They want to flag this up to their subscribers, without creating a permanent trivially-findable public record. They make a public posting, intending to manually restrict access to said post after a week. Memory proves to be a tricksy beast, however.

(2) person wants their "current" entries to be public - on a rolling basis. That is, they *don't* want their entire journal to be public, but *do* want their initially-set-as-public posts over the last N weeks to be generally visible.

(3) person is making a links round-up (LRU); realises they've left out a link; edits the original post to include it. In order to flag this up to people who've already read the LRU and won't read closely again, they make a follow-up post to appear on people's dwrolls, highlighting that they've added a new link, with the intention of deleting the follow-up post after a few hours (at which point it is obsolete, because people who're only just catching up with their reading lists won't have seen the pre-edit LRU anyway!)

In each of these cases, it would be helpful if there were the option tree at point of posting:

Change security at later date? Y/N
Change security to? [pre-defined set of access filters, etc!]
Change security when? [hours, days, weeks...]

... such that in case:

(1) person, at time of posting, can say "make this post access-locked after a week"
(2) user can set a default behaviour of "increase privacy of all posts to [LEVEL] after a month" (where custom filters, etc obviously don't have their privacy level *reduced*!)
(3) user can make the post automatically set itself private e.g. 6 hours after initially posting

In IRC we briefly discussed the possibility of actual self-destruct - i.e. automatic deletion after a set time frame - but consensus there was that auto-deletion is an undesirable behaviour, because (a) deletion is irreversible, and (b) setting posts to private has the same effect on the reader as deleting them.

In terms of downsides, the only one that springs out at me is that - at least for my level of familiarity with the code-base - this would be an absolute *swine* to implement. However, I am very open to hearing other criticisms :-)

Poll #11815 "This post will self-destruct shortly...": automated security changes

Open to: Registered Users, detailed results viewable to: All, participants: 65

View Respondents

This suggestion:

View Answers

Should be implemented as-is.
26 (40.0%)

Should be implemented with changes. (please comment)
10 (15.4%)

Shouldn't be implemented.
13 (20.0%)

(I have no opinion)
15 (23.1%)

(Other: please comment)
1 (1.5%)

marahmarie

Title:
Add the ability for logged-in users to visibly sort the Tags Page by access level.

Area:
Styles

Summary:
There is currently a hidden feature on the Visible Tags Page: the ability to show the approximate access-level assigned to each tag. I would like DW to add CSS or a combination of JavaScript and CSS to all our journals to show the hidden feature to everyone who opts-in.

Description:
Currently the Visible Tags page shows all your tags in a single, alphabetically sorted list but does not *visibly* indicate which tags are used on private, access-list-only or public posts. So one day about a year ago I asked myself, "Why not?" and wound up writing CSS that exposed the access-level of all my private and access-list-only posts. This became a fantastic sorting system since I have no other way to tell what I've thrown where without using the Manage Tags page, which can be kind of awkward and time-consuming.

So a week ago I took this a little further and refined the CSS so that 1) only logged-in users see the access-levels alongside each tag and 2) logged-in users see the exact access level used on each tag - public, private, or access-list-only. Here's a screen cap of my current Visible Tags page using my latest CSS for it (logged-in view - logged-out you won't see any of the extra information shown in this screen cap):
http://i287.photobucket.com/albums/ll128/marahstest/expose_access-level_tags_page.jpg

What I'm humbly hoping for is this system of sorting tags by access-level, as seen in the screen cap, gets adapted site-wide either as the default view on the Visible Tags page (of course, it will be visible to logged-in users by access-level only) or else becomes an opt-in default option (which is where JavaScript would probably come into play; otherwise, this is a pure CSS hack).

There are a few possible issues with adapting this styling: 1) it may take more firepower to serve up the additional CSS (but I'm thinking it would not be enough to crash servers or do anything that dramatic as things stand; it's just hard to calculate how much this might slow things down without knowing how much firepower DW has to spare) and 2) there is currently an issue where if you use a tag at more than one access level (say you use your "cats" tag both publicly and on several access-list-only posts) it will get an HTML tag indicating it's for public use only, which means DW won't be able to style it with the specific CSS to reflect that you used it three times publicly and three times for access list readers. Until that split-usage quirk is fixed, my idea makes for an imprecise-at-best look at how your tags are being used. But I think it's still better than not having any sorting system in place at all; in the meantime you can still use your Manage Tags page to drill down more precisely.

If this were to get adopted, I could see future improvements to it such as sorting tags by access level on the Visible Tags Page instead of sorting them entirely alphabetically as we do now, adding the ability to style each access level separately, and so on.

Poll #11751 Add the ability for logged-in users to visibly sort the Tags Page by access level.

Open to: Registered Users, detailed results viewable to: All, participants: 47

View Respondents

This suggestion:

View Answers

Should be implemented as-is.
15 (31.9%)

Should be implemented with changes. (please comment)
0 (0.0%)

Shouldn't be implemented.
3 (6.4%)

(I have no opinion)
28 (59.6%)

(Other: please comment)
1 (2.1%)

kunzite

Title:
Aggregate External Identities (like OpenID)

Area:
profile

Summary:
A list of OpenID identities to be shown on my profile page.

Description:
I have a lot of OpenID identities across the internet. I do not have a place to put this information where it can be authenticated appropriately.
Ideally, this information would be displayed on my profile page, with degrees of privacy settings.

I trust Dreamwidth with this information. Not all users will. Your mileage may vary. People should be informed about what this trust entails.

Poll #11692 Aggregate External Identities (like OpenID)

Open to: Registered Users, detailed results viewable to: All, participants: 45

View Respondents

This suggestion:

View Answers

Should be implemented as-is.
16 (35.6%)

Should be implemented with changes. (please comment)
0 (0.0%)

Shouldn't be implemented.
7 (15.6%)

(I have no opinion)
21 (46.7%)

(Other: please comment)
1 (2.2%)

msilverstar

Title:
cut expander should show error when accessing protected post

Area:
page: reading, cut tags

Summary:
Right now, if a reader had access to an entry but doesn't any more, clicking on the cut expander doesn't open the cut -- correct behavior -- but also doesn't display an error message. It's very confusing. Clicking on the cut itself takes the reader to an error page where all is made clear, so a little JavaScript error on the reading would be nice.

Description:
Granted corner case, having opened a reading page when one had access but no longer, due to the poster changing the security, the reader logging out in another tab or window, or the system logging the reader out.

In that case, clicking the disclosure triangle to expand the cut flickers but doesn't expand, and doesn't explain why. It seems like the features is broken. Better error handling would be good.

Poll #11556 cut expander should show error when accessing protected post

Open to: Registered Users, detailed results viewable to: All, participants: 52

View Respondents

This suggestion:

View Answers

Should be implemented as-is.
47 (90.4%)

Should be implemented with changes. (please comment)
0 (0.0%)

Shouldn't be implemented.
0 (0.0%)

(I have no opinion)
5 (9.6%)

(Other: please comment)
0 (0.0%)

syderia

Title:
Default security settings for tags

Area:
security settings

Summary:
Journals would still have a global default access setting, but it would be possible to set other access settings for specif tags - those settings would then override the default when chosen on an entry.

Description:
In case two tags were chosen with different settings, the more restrictive one would be picked.
The possibility to manually set the access level for the entry would stay there and would override any tag-specific level.

This might be a nice paid feature. The number of tags that could be associated to another access setting could be limited (and scaled depending on the type of account).

Poll #11555 Default security settings for tags

Open to: Registered Users, detailed results viewable to: All, participants: 45

View Respondents

This suggestion:

View Answers

Should be implemented as-is.
11 (24.4%)

Should be implemented with changes. (please comment)
2 (4.4%)

Shouldn't be implemented.
15 (33.3%)

(I have no opinion)
16 (35.6%)

(Other: please comment)
1 (2.2%)

swaldman

Title:
Tidy up the Edit Profile page

Area:
Edit Profile

Summary:
The Edit Profile page needs a tidy, especially when it comes to controlling who can see what.

Description:
I think that the Edit Profile page is needlessly confusing at present, especially for those not used to LJ-a-likes.
I think it could do with general thinking-through and cleaning up, but here are some specific things that I've noted. Let me know if I should resubmit them as separate suggestions.

* When I want to control who can see which bits on my profile, some things are set here and some are set over in Account Settings -> Privacy (under Contact Info Security and DW Private Messages). Some things are set in Account Settings but then overridden in Edit Profile! I don't know whether this is pure historical legacy, or whether it's because the stuff that's in Account Settings applies more widely than just the profile, but I think it's confusing.

* I can't exercise any control over who can see website URLs that I enter. This is already covered by another suggestion (http://dw-suggestions.dreamwidth.org/404239.html), I'm just mentioning it here for completeness.

* There is a line that reads "DW Private Messages: OBSOLETE: This option has been moved to Account Settings". Why is this here at all?

* There is no granular control over who can see IM usernames. The access level for all contact info (email, Yahoo, Etsy, Gtalk, Jabber, Skype, Twitter, etc etc etc) is set in Account Settings. I think it would be good to be able to control the visibility of each contact method individually.

None of this is important or urgent, but I think giving this page a clean-up at some stage would be a Good Thing :-)

Poll #11118 Tidy up the Edit Profile page

Open to: Registered Users, detailed results viewable to: All, participants: 46

View Respondents

This suggestion:

View Answers

Should be implemented as-is.
13 (28.3%)

Should be implemented with changes. (please comment)
2 (4.3%)

Shouldn't be implemented.
7 (15.2%)

(I have no opinion)
22 (47.8%)

(Other: please comment)
2 (4.3%)

azurelunatic

Title:
(Optional!) Interaction analytics and suggestions

Area:
circle management

Summary:
Allow the option to automatically suggest circle modifications, a la Facebook except with less creepy.

Description:
The thought that the website is watching you and has all sorts of helpful suggestions about your personal life is at heart amazingly creepy. Despite the fact that you trust the website for rather a lot does not mean that you actually want the website peering over your shoulder.

However, that changes if you invite the website to peer over your shoulder, and know the things that the website will be looking at. It's the permission that changes the perspective, and while knowing the factors is counter to a "this is our proprietary algorithm" outlook *cough*facebook*cough*, it sounds positively Dreamwidthy. It should also have an easy and intuitive way to turn it off, if it winds up not being what a user wanted for whatever reason.

If turned on, the analytics could suggest possible interactions between users, such as: "You comment to Anna and read their journal more than many other users who are not on your reading list. Do you want to add Anna to your reading list?" or "You have deleted 99% of the comments left by Bit in your journal in the last 2 weeks. Do you want to ban Bit from commenting?"

This might introduce users to features they were not previously aware of.

Any suggestion should be able to be ignored or declined; ignored (no interaction with suggestion) would be left in place; declined suggestions would go away and not come back; declined suggestions would have the option for the user to leave a note; declined suggestions would be listed in a user-accessible place, along with the notes (if any). Saving the declined suggestions would let the user recover from dismissing a suggestion if they did not mean to, and the notes would be a reminder of why the user dismissed that particular suggestion, in case things changed later (for example: "Add Charlotte to reading list?" might have been dismissed with "I'm not interested in Iron Man"; upon looking in the bin later, the user might re-visit their decision on the grounds that they love the Avengers now.)

Poll #10463 (Optional!) Interaction analytics and suggestions

Open to: Registered Users, detailed results viewable to: All, participants: 50

View Respondents

This suggestion:

View Answers

Should be implemented as-is.
6 (12.0%)

Should be implemented with changes. (please comment)
0 (0.0%)

Shouldn't be implemented.
25 (50.0%)

(I have no opinion)
15 (30.0%)

(Other: please comment)
4 (8.0%)

Dreamwidth Suggestions

Unscreen your comments from Post Comment Success page

Show poster is banned from quickreply

Suppress content in inbox notification

Reconsidering the Ability to Delete All Entries/Comments Associated With an Account Upon Deletion

In Case of Emergency write-only access

Password protect posts so non-DW friends can be included

Send notifications of unscreened comments in tracked threads

Option for Blind Polls Until Closed

Save selected icon when having to re-login to post a comment

"Display crosspost link" should be retroactive

Some privacy incoherence

Notifications to detect spoofing if posting by email

Allow comments by replying to email notification

"This post will self-destruct shortly...": automated security changes

Add the ability for logged-in users to visibly sort the Tags Page by access level.

Aggregate External Identities (like OpenID)

cut expander should show error when accessing protected post

Default security settings for tags

Tidy up the Edit Profile page

(Optional!) Interaction analytics and suggestions

Profile

Most Popular Tags

December 2018

Page Summary

Active Entries

Style Credit

Expand Cut Tags

Syndicate