07/24/2018 05:51 PMPosted by Moirasha07/24/2018 05:39 PMPosted by GruuhrAlso, officers can view messages posted in officer chat prior to their promotion.
This is not a good idea.
hahahahaha..
yeah, this needs to go
RIGHT?! It's insane!
RIGHT?! It's insane!
07/24/2018 05:26 PMPosted by Annaillusion07/24/2018 05:20 PMPosted by Daugil...
Can we get at least an explanation of what happened and if it's going to stay or not, or are you just doing this so the complaints can all be shepherded to one thread? I mean, if you don't know, you don't know, it'd just be nice to hear something. The silence is deafening.
My guess if they are extending the thread they are gathering the useful feedback provided here. Which would then be put up to discussion during a meeting when there is enough useful information to bring.
But by extending the thread, they can close any other threads on the topic and direct all comments on the issue here - sort of a contain and somewhat limit the outcry strategy.
Maybe it makes it easier to gather and consolidate feedback, maybe it's a strategy to limit the topic's footprint on the forums - you can be the judge of that! :)
/moo
07/24/2018 05:51 PMPosted by Moirasha07/24/2018 05:39 PMPosted by GruuhrAlso, officers can view messages posted in officer chat prior to their promotion.
This is not a good idea.
hahahahaha..
yeah, this needs to go
“Omg so like Momocow is sooo dumb I mean his DPS is like he’s level 1”
“I totes agree. Plus I heard he doesn’t floss...”
momocow has been promoted to officer
“Sup Guys!”
“Crap.....”
Plus side...at least you know what you walked into now when you log on.
This is one of those changes that should be reverted. A lot of GMs like to have different permissions for different ranks, some of which may overlap traditional "officer" permissions but not mirror them.
In instances like this, Blizzard would always err on the side of player control/choice.
In instances like this, Blizzard would always err on the side of player control/choice.
07/24/2018 05:57 PMPosted by Sassiekal07/24/2018 05:51 PMPosted by Moirasha...
hahahahaha..
yeah, this needs to go
“Omg so like Momocow is sooo dumb I mean his DPS is like he’s level 1”
“I totes agree. Plus I heard he doesn’t floss...”
momocow has been promoted to officer
“Sup Guys!”
“Crap.....”
Plus side...at least you know what you walked into now when you log on.
I'd love to live in a world where that was the worst that will happen as a result of this change.
1 Like
I don't really complain I do like the community thing. However one thing I don't like is the chat log. That's a bit freaky. I'm sure it's intended to be that way to keep people from just speaking their mind.
07/24/2018 05:39 PMPosted by GruuhrAlso, guild chat hangs around forever. New guild members can see what was posted in guild chat prior to them joining. Also, officers can view messages posted in officer chat prior to their promotion.
This is not a good idea.
In point of fact, that is an acutely terrible Idea.
Blue lets ponder it this way. I will pretend to be you for a few moments of hypothetical time if I may?
I and my team are making decisions on who to bring up into the fold of developers. My team sends me and I send them emails on the candidates and the reviews by my teammates of those candidates. In those emails we talk about positives and negatives of personality of potential fitness of potential work ethic etc. These emails are only distributed between myself and my team and HR. A new candidate comes on board and now has access not only to new communications but to previous conversations in email. They also end up with HR's assessments as well. Could you please posit for us how my emails (filled with good intent though they are) might violate not only HR policy but harm the relationship of the new team member and the team and myself?
Same thing with the guild officer chat. It is not a good idea to allow information to hang out beyond its retention schedule. It causes problems. Problems that cost money.
I'm going to argue against Blizzard in the case of the guild control changes but not in the context most are presently doing.
As Blizzard's security staff knows, when doing role-based access control permissions (and/or profiles), the principle of "Least Privilege" applies. This, in lay terms, means "Only what permissions are required to do the necessary tasks for that job role".
In this context, I am not comfortable granting a person who I did not designate an officer to have all officer permissions. Nor do I necessarily want to grant an officer all of the current permissions. In my guild hierarchy, the structure only allows 3 people to invite to the guild AND remove from the guild even though we may have a separate structure for officers.
(This is to combat the notion that 1 person is the benevolent dictator {i.e. GM}. We have a council of 3 Founders. If 2 disagree, I act as the tie-breaker as the "GM". Generally speaking, we don't disagree, but we can.)
I have a separate tier of "officers" in the context that most guilds use them today. These do my guild recruiting, raid leading, and class officer roles that most guilds have today. However, I do not grant them the ability to remove individuals from the guild nor would I.
This is a way of decentralizing power but also not providing a scenario where officers might disagree and act against each other intentionally or otherwise. They should be able to discuss this as a group and make the recommendation to the Founders. As a rule, I tend to let the two Founders handle those disputes (we really don't see any, but that's why the structure is there). I know both of the other Founders in person and I trust both implicitly, so it is a simple phone call or text from either of them to get my opinion if a tie should result.
In this context, as a person who has drafted security policies in a past architect role and as a current Operations Manager role, I am disinclined to give ranks permissions that I do not want them to have. It was granularly set in this fashion for a very good reason - and it is a technical control to help ensure that officers in my guild can't act on a whim.
While my vetting process is actually pretty good, it isn't perfect as nothing can be perfect. You're removing my ability to set practical guild permissions for the sake of simplifying the experience. I don't mind if there's a "simple" mode for folks who don't want to manage it, but give me an "advanced" mode so that folks who want to manage those things can.
As Blizzard's security staff knows, when doing role-based access control permissions (and/or profiles), the principle of "Least Privilege" applies. This, in lay terms, means "Only what permissions are required to do the necessary tasks for that job role".
In this context, I am not comfortable granting a person who I did not designate an officer to have all officer permissions. Nor do I necessarily want to grant an officer all of the current permissions. In my guild hierarchy, the structure only allows 3 people to invite to the guild AND remove from the guild even though we may have a separate structure for officers.
(This is to combat the notion that 1 person is the benevolent dictator {i.e. GM}. We have a council of 3 Founders. If 2 disagree, I act as the tie-breaker as the "GM". Generally speaking, we don't disagree, but we can.)
I have a separate tier of "officers" in the context that most guilds use them today. These do my guild recruiting, raid leading, and class officer roles that most guilds have today. However, I do not grant them the ability to remove individuals from the guild nor would I.
This is a way of decentralizing power but also not providing a scenario where officers might disagree and act against each other intentionally or otherwise. They should be able to discuss this as a group and make the recommendation to the Founders. As a rule, I tend to let the two Founders handle those disputes (we really don't see any, but that's why the structure is there). I know both of the other Founders in person and I trust both implicitly, so it is a simple phone call or text from either of them to get my opinion if a tie should result.
In this context, as a person who has drafted security policies in a past architect role and as a current Operations Manager role, I am disinclined to give ranks permissions that I do not want them to have. It was granularly set in this fashion for a very good reason - and it is a technical control to help ensure that officers in my guild can't act on a whim.
While my vetting process is actually pretty good, it isn't perfect as nothing can be perfect. You're removing my ability to set practical guild permissions for the sake of simplifying the experience. I don't mind if there's a "simple" mode for folks who don't want to manage it, but give me an "advanced" mode so that folks who want to manage those things can.
2 Likes
07/24/2018 05:18 PMPosted by Ythisens07/24/2018 01:59 PMPosted by RestomakWe're at 23 pages now, and I suspect this thread will soon get locked without a page extension by Blizzard. I'm going to bump my own post made about this very exact topic. Feel free to continue there if this gets locked.
https://us.battle.net/forums/en/wow/topic/20766206706
This isn't needed as I've extended the thread cap on this one. Thanks guys!
Thank you for the extend Ythisens. Hopefully we can get some insight on the changes soon when things are a bit more calm.
07/24/2018 06:30 PMPosted by AngosiaI'm going to argue against Blizzard in the case of the guild control changes but not in the context most are presently doing.
As Blizzard's security staff knows, when doing role-based access control permissions (and/or profiles), the principle of "Least Privilege" applies. This, in lay terms, means "Only what permissions are required to do the necessary tasks for that job role".
In this context, I am not comfortable granting a person who I did not designate an officer to have all officer permissions. Nor do I necessarily want to grant an officer all of the current permissions. In my guild hierarchy, the structure only allows 3 people to invite to the guild AND remove from the guild even though we may have a separate structure for officers.
(This is to combat the notion that 1 person is the benevolent dictator {i.e. GM}. We have a council of 3 Founders. If 2 disagree, I act as the tie-breaker as the "GM". Generally speaking, we don't disagree, but we can.)
I have a separate tier of "officers" in the context that most guilds use them today. These do my guild recruiting, raid leading, and class officer roles that most guilds have today. However, I do not grant them the ability to remove individuals from the guild nor would I.
This is a way of decentralizing power but also not providing a scenario where officers might disagree and act against each other intentionally or otherwise. They should be able to discuss this as a group and make the recommendation to the Founders. As a rule, I tend to let the two Founders handle those disputes (we really don't see any, but that's why the structure is there). I know both of the other Founders in person and I trust both implicitly, so it is a simple phone call or text from either of them to get my opinion if a tie should result.
In this context, as a person who has drafted security policies in a past architect role and as a current Operations Manager role, I am disinclined to give ranks permissions that I do not want them to have. It was granularly set in this fashion for a very good reason - and it is a technical control to help ensure that officers in my guild can't act on a whim.
While my vetting process is actually pretty good, it isn't perfect as nothing can be perfect. You're removing my ability to set practical guild permissions for the sake of simplifying the experience. I don't mind if there's a "simple" mode for folks who don't want to manage it, but give me an "advanced" mode so that folks who want to manage those things can.
I would like to expound on this topic and actually focus in on the principle stated in the second paragraph. Specifically the Principle of Least Privilege. There are literally enough volumes on this concept to fill libraries to overflowing.
The Principle of Least Privilege (PoLP) is the standard of Information Security that is adhered to by most if not all corporations (both public and private) government agencies (whether Global Federal State or Local in scope). It is the heart and soul of profile or role based security systems.
At its heart PoLP maintains that you only give the least permissions to a role that is necessary for that role to perform its function. You then assign users to that specific role so that should you need to change the scope of the role and the users in that role you do it once and each member then has the role's scope adjusted.
It saves the administrator time and effort in having to track down all the users of a role. He simply need only change the permissions assigned to that role.
Likewise if a user must be removed from a role there is no need to change the other users permissions you simply remove that person from the role. This can save enormously valuable time if the user is found to be a bad actor. You remove that users role from them while not disturbing the operations of others and prevent the bad actor from causing damage to you system.
Then there is the implied concept of granularity in the PoLP. Invoking PoLP allows the administrator to clearly define a role by assigning certain permissions to that role and not others.
A guild raid leader might need more access to guild bank resources and or guild reward systems for loot from bosses than a Class Officer might need. Similarly a Production Fire Team might need read access to Production Servers but probably should not be given write or modify permissions. A Production DBA who is the DB Owner might need read write and modify but certainly should not have sa privileges on a DB he does not own and likely should not have remote access OS Level permissions to a Production server.
By compromising this system intentionally, by flagging all of the above roles as simply Officer, you invite disaster.
You invite the accidental or incidental promotion of a bad actor to a level that has access to the guild bank and can then rob that guild blind. Then you have GL's sending in tickets for recovery of items and demanding (rightfully so since you put them in that position by lumping all Officer roles under one set of permissions) that they be reimbursed for the items.
Then you start getting false reports from gl's that think they can 'game' the system by filing false tickets and getting items they never had. This creates FAR more work for your GM's than you had previously slowing down the system AND making you hire more of them to handle the unexpected volume.
But lets turn the tables just for an instance. What if tomorrow you came in to work and all of the permissions for all of the data in your corporation were set to a single role. Could you be expected to continue business as usual? No? Then you have your answer for GL's too.
07/23/2018 02:33 PMPosted by Polgara(Now for a “nice to have”)
If we are asking for new features, while I can think of several, the one thing I always thought was a glaring omission was having separate permissions for:
• Edit Own Public Note
• Edit All Public Notes
Thank you.
In games I played before I started playing wow, the version of "public notes" found in the guilds there were something that only the player of that particular character could write. I always though wow was doing this wrong, after all, if it's my public note, I should be the only one who can write it. Then there was a version of "officer notes" which any officer could modify... which is how wow handles both officer notes and public notes now.
07/24/2018 06:58 PMPosted by ÆthelwulfI would like to expound on this topic and actually focus in on the principle stated in the second paragraph. Specifically the Principle of Least Privilege. There are literally enough volumes on this concept to fill libraries to overflowing.
The Principle of Least Privilege (PoLP) is the standard of Information Security that is adhered to by most if not all corporations (both public and private) government agencies (whether Global Federal State or Local in scope). It is the heart and soul of profile or role based security systems.
Thank you! It's nice to see another of my stripe around. Rare as we may be.
As you saw in my post, I'm all for giving both modes to players. Simple for those who don't want to manage those permissions (and agree to the concept that simple setup right now probably means more trouble later) and Advanced for those who do want to manage those permissions (and agree to the concept that advanced now means longer initial setup now and less trouble later).
I like how you called out the role-based reasoning for adding/removing folks from permission groups/roles. That's something that folks outside of security don't usually get to see. In the context of the game, that's why the "Ranks" are in the guild (and you can set the permissions per rank and set the rank name). They're security profiles such that you can have more or less permissions.
Blizzard's recent change to the permissions model sacrifices "principle of least privilege" for simplicity. And anyone in the security space will tell that is almost always a recipe for disaster. Not only conceptually in a theoretical space, but I also provided a real-world example of why it was set the way it is.
Giving a guild the option to choose simple or advanced security models makes sense. It's the same things companies do now: You choose to have less security for the less hassle upfront, but the security folks know on the back-end that it creates a mound of issues later on... OR, you can take more time to set it up the right way at the start and have less changing to do later on with a clearly defined access control policy and technical controls to enforce the aforementioned policy.
07/24/2018 05:18 PMPosted by YthisensThis isn't needed as I've extended the thread cap on this one. Thanks guys!
Thank you.
07/24/2018 05:39 PMPosted by GruuhrAlso, guild chat hangs around forever. New guild members can see what was posted in guild chat prior to them joining. Also, officers can view messages posted in officer chat prior to their promotion.
This is not a good idea.
Huh, didn't even notice this was a possible thing - thanks for pointing that out! :) I'm sure a lot of guild leaders will like that tidbit of information.
Along with that, it probably should be changed.
07/24/2018 06:30 PMPosted by AngosiaI'm going to argue against Blizzard in the case of the guild control changes but not in the context most are presently doing.
As Blizzard's security staff knows, when doing role-based access control permissions (and/or profiles), the principle of "Least Privilege" applies. This, in lay terms, means "Only what permissions are required to do the necessary tasks for that job role".
In this context, I am not comfortable granting a person who I did not designate an officer to have all officer permissions. Nor do I necessarily want to grant an officer all of the current permissions. In my guild hierarchy, the structure only allows 3 people to invite to the guild AND remove from the guild even though we may have a separate structure for officers.
(This is to combat the notion that 1 person is the benevolent dictator {i.e. GM}. We have a council of 3 Founders. If 2 disagree, I act as the tie-breaker as the "GM". Generally speaking, we don't disagree, but we can.)
I have a separate tier of "officers" in the context that most guilds use them today. These do my guild recruiting, raid leading, and class officer roles that most guilds have today. However, I do not grant them the ability to remove individuals from the guild nor would I.
This is a way of decentralizing power but also not providing a scenario where officers might disagree and act against each other intentionally or otherwise. They should be able to discuss this as a group and make the recommendation to the Founders. As a rule, I tend to let the two Founders handle those disputes (we really don't see any, but that's why the structure is there). I know both of the other Founders in person and I trust both implicitly, so it is a simple phone call or text from either of them to get my opinion if a tie should result.
In this context, as a person who has drafted security policies in a past architect role and as a current Operations Manager role, I am disinclined to give ranks permissions that I do not want them to have. It was granularly set in this fashion for a very good reason - and it is a technical control to help ensure that officers in my guild can't act on a whim.
While my vetting process is actually pretty good, it isn't perfect as nothing can be perfect. You're removing my ability to set practical guild permissions for the sake of simplifying the experience. I don't mind if there's a "simple" mode for folks who don't want to manage it, but give me an "advanced" mode so that folks who want to manage those things can.
07/24/2018 07:32 PMPosted by Calathiel07/24/2018 05:39 PMPosted by GruuhrAlso, guild chat hangs around forever. New guild members can see what was posted in guild chat prior to them joining. Also, officers can view messages posted in officer chat prior to their promotion.
This is not a good idea.
Huh, didn't even notice this was a possible thing - thanks for pointing that out! :) I'm sure a lot of guild leaders will like that tidbit of information.
Along with that, it probably should be changed.
Yeah and if you delete the message it sticks out like a sore thumb like "Carhorinn deleted this message" so even if you do it for damage control people still go WTF is with the deleted messages LOL
Our Guild is based very much like the one mentioned. For years we have tried to build a respectable guild. I feel that our Guild along with many others on the server have been the backbone of WOW. Setting examples of respect, friendship and drama free environment. To have the latest changes thrust upon the very ones that have worked so hard is offensive and beyond reasoning. We were very limited in the controls we had to help us and now that is gone. It seems to me the ones that have cared the most and did everything that they could to make your game enjoyable have been brushed aside. I feel as if Guilds have been given a pink slip. Thanks Blizzard!
07/24/2018 07:48 PMPosted by Mizbehaving07/24/2018 06:30 PMPosted by AngosiaI'm going to argue against Blizzard in the case of the guild control changes but not in the context most are presently doing.
As Blizzard's security staff knows, when doing role-based access control permissions (and/or profiles), the principle of "Least Privilege" applies. This, in lay terms, means "Only what permissions are required to do the necessary tasks for that job role".
In this context, I am not comfortable granting a person who I did not designate an officer to have all officer permissions. Nor do I necessarily want to grant an officer all of the current permissions. In my guild hierarchy, the structure only allows 3 people to invite to the guild AND remove from the guild even though we may have a separate structure for officers.
(This is to combat the notion that 1 person is the benevolent dictator {i.e. GM}. We have a council of 3 Founders. If 2 disagree, I act as the tie-breaker as the "GM". Generally speaking, we don't disagree, but we can.)
I have a separate tier of "officers" in the context that most guilds use them today. These do my guild recruiting, raid leading, and class officer roles that most guilds have today. However, I do not grant them the ability to remove individuals from the guild nor would I.
This is a way of decentralizing power but also not providing a scenario where officers might disagree and act against each other intentionally or otherwise. They should be able to discuss this as a group and make the recommendation to the Founders. As a rule, I tend to let the two Founders handle those disputes (we really don't see any, but that's why the structure is there). I know both of the other Founders in person and I trust both implicitly, so it is a simple phone call or text from either of them to get my opinion if a tie should result.
In this context, as a person who has drafted security policies in a past architect role and as a current Operations Manager role, I am disinclined to give ranks permissions that I do not want them to have. It was granularly set in this fashion for a very good reason - and it is a technical control to help ensure that officers in my guild can't act on a whim.
While my vetting process is actually pretty good, it isn't perfect as nothing can be perfect. You're removing my ability to set practical guild permissions for the sake of simplifying the experience. I don't mind if there's a "simple" mode for folks who don't want to manage it, but give me an "advanced" mode so that folks who want to manage those things can.
07/24/2018 07:05 PMPosted by AngosiaIt's the same things companies do now: You choose to have less security for the less hassle upfront, but the security folks know on the back-end that it creates a mound of issues later on... OR, you can take more time to set it up the right way at the start and have less changing to do later on with a clearly defined access control policy and technical controls to enforce the aforementioned policy.
In today's information-as-product environment you have to know about the five classification levels of information:
- Public
- Internal Use
- Restricted
- Confidential
Each of those classifications of information have implied exposure, access, risk, and retention schedules. The PoLP was discovered over time and agreed to be the best solution to resolve the problems of exposure access risk and retention of information.
Public information is the lowest level of information security. Anyone has access to it and usually its better if everyone does have access to it as these are generally fliers for products, advertisements, promotions and other things that are used to generate revenue.
Internal Use (lawyers and other professionals often refer to it as work product), is the "sharp knives hot stoves and other machinery in the restaurant kitchen" Raph Kimball always talked about in reference to data warehouse development. Its necessary for the developer to see it. Necessary for the business people to see it, but unnecessarily complicates interactions with customers if the customer is exposed to it. Work Flows, Venn Diagrams, Data Bus Matrices etc. All are usually considered work product and labeled Internal Use
Restricted information: Information that if exposed to the general public may increase operational, reputational, compliance, strategic, or regulatory risk.
This is the stuff that if you divulge it HR and you are going to discuss your future with the company if any and potentially discuss the color of the wall coverings in the cinderblock institution you may soon be a new resident at.
Confidential information: Information that if exposed could cause other people, customers, business partners, vendors, contractors and employees, immediate harm in the form of loss of reputation, violation of compliance and or regulatory rules which in turn result in regulatory risk in the form of fines and loss of stature within the community. Divulge this stuff you are going to be out on your ear at the end of the day and district attorney is likely going to be looking to use your backside to decorate his wall while every newspaper and media outlet scream DATA BREACH THOUSANDS OR MILLIONS AFFECTED.
Without the tools (the PoLP) to be granular enough Data Loss is a near certainty. Data Exposure of Restricted and above PII is also close on to a certainty.
The guild leaders need these tools as they have just as much a duty to their guildmates at every level to protect their data and their inventory as their real world counterparts do.
If it is illegal to divulge CPII in the real world (it is. HIPAA, BSA. PPAAFCA, FCRA, and the list goes on interminably just to name a few that provide severe penalties for divulging CPII), then the virtual world should be doubly careful about its data and its inventories as the speed at which that data makes the rounds is measured in lengths of copper wire 11.8 inches long according to the Good Admiral (Lower Half) Hopper.
Taking away the tools that allow the guild leader to structure his guild is tantamount to making him divulge his company secrets.
07/24/2018 07:52 PMPosted by CarthorinnYeah and if you delete the message it sticks out like a sore thumb like "Carhorinn deleted this message" so even if you do it for damage control people still go WTF is with the deleted messages LOL
Which I actually prefer. Since I cannot take that permission -away-, at least I can tell if the power was used, who used it, and who they used it on. As my officers have all been told "Don't do this. Just. Don't." that very important to me.
Not only that, but if a player sets themselves as "offline," they do not show up when they are on in a guild.