Closed. This question needs to be more focused. It is not currently accepting answers.
Want to improve this question? Update the question so it focuses on one problem only by editing this post.
Closed 5 years ago.
Improve this question
Just found about this new regulation, it will be law in 2018 and affects anybody who stores data about EU citizens, that can be used to identify a person. More detail here.
I have a page that doesn't store names and exact addresses but it stores birth dates and country/city as location and uses these two to provide a service (which is the core service, so I can't just stop collecting these data).
From what I understand I have to take some action to ensure compliance with GDPR, but I haven't found reasonable explanations what that means. There is a dozen articles that rephrase paragraphs of GDPR, that is not helping at all.
I don't mind full deletion, explaing what data I store to the users and simmilar points ... What I am mostly worried about is the part about anonymizing data so in case of a breach they can not be used to identify a person. How am I supposed to do that? If I store an email address used to verify an user account and tie birth date and location data via PK to that verified email, they are no longer anonymous ... and they can't be, right?
Any thought about practical solutions to become GDPR compliant?
Ultimately, in the UK, the GDPR will be enforced by the ICO - Information Commissioners Office. Whilst some of the regulation is quite clear cut, the articles relating to anonymisation are open to interpretation and we'll probably only fully understand how the line is drawn once the ICO has enforced a case relating to it. Having said that there is a bunch of good info on their site.
Their is also a group of academics in the UK advising both the ICO and businesses (for free) about anonymisation. They're called the UK Anonymisation Network - UKAN. I've had a web meeting with them - they're awesome.
It is unlikely you will have to anonymise your data if you use standard encryption to store your data at rest. Anonymisation may come in handy if you are sharing any of that data with third parties. In the event of a breach on their system, you can demonstrate you have taken as many steps as possible to mitigate your risk.
I agree with the above - GDPR is a great thing for privacy rights and data control - I also agree that there are a million sites out there just rephrasing gdpr!
In terms of practical steps, more guidance is going to be released by the ICO this month. But it makes sense to begin by mapping out what user data you process, whether the reasons for this are justified and whether there you have asked for EXPLICIT permission to use that data in that way. Further to this you should think about how you can delete data if it's requested.
There are services that will keep independent record of opt ins and alert you to data vulnerabilities. Anonomisation works in some cases, in others, if you have permission, then all you need is process to delete and an audit trail.
Related
Closed. This question does not meet Stack Overflow guidelines. It is not currently accepting answers.
This question does not appear to be about programming within the scope defined in the help center.
Closed 2 years ago.
Improve this question
I am currently developing a Website which allows users to create Blog-posts and was wondering whether I should allow them to delete their Posts from the Database. On one hand, they could be writing illegal stuff and delete it shortly afterwards, which would make it impossible to follow up on this issue afterwards, on the other I might have to provide such a feature. I was thinking about implementing a "soft-deletion", which allows users to mark a posts as deleted and deleting all marked posts after a couple of weeks.
My question now is whether this approach would be legal, especially considering the GDPR. How would you go about it?
I'm aware that I might be in the wrong community (Stackoverflow) here and am open for suggestions for other forums.
Edit
The website is hosted and has its Guests mostly in Germany. Does anybody know about the lokal laws and how they play for this problem?
GDPR is only concerned with personal data, which is data connected with people, so if I write a blog post that doesn't contain any personal data, GDPR simply doesn't enter into it except for identifying me as its author. With that link removed, it's just regular data.
If you consider the blog post along with its author identification as a single item, then it would count as personal data, and they could ask for it to be deleted. There is some wiggle room for practicality here though. You can reasonably do as you suggest and soft delete now and really delete later, but you should make it clear in your privacy policy that that is what you are going to do. You could cite a reasonable case of legitimate interest to allow for letting data fall off the end of backup cycles, allowing a grace period for them to change their mind, accidental deletion, and abuse.
A separate issue is copyright, which remains with the author regardless of whether they are credited (unless for example they write it under contract to you and waived their rights or assigned ownership to you).
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 5 years ago.
Improve this question
What's a good way to capture user stories when you have features that are common across multiple UI modes?
For example, imagine a commercial flight information system, something someone might use to answer the question "When is flight UA211 expected to land?"
As is often the case, the feature of providing schedule information is common underlying functionality, even though you might ask for it via a desktop web browser, a mobile browser (where you want to apply different style to make it more usable), and maybe even via SMS shortcodes.
Now, that certainly could be a single user story ("As someone meeting a traveller, I want to see flight arrival information so that I can be at the airport on time"). But that seems wrong (and would probably be an epic story, anyway).
You can make it separate user stories ("As a desktop user...", "As a smartphone user...", etc), which I've done in the past, and the team just knows to estimate the first one to include all of functionality, and the subsequent ones to estimate only UI implementation.
A third option is to make the underlying functionality a story isolated from the presentation layer, and then have UI stories: "As a flight info system front end, I want to get flight status information so that I can present it to the user", "As a desktop user, I want to see flight arrival... etc". But that seems artificial.
Thoughts?
dwh
I think the problem is that you are trying to tie the UI functionality to the backend too tightly.
For example, if you break it into a simple story:
A user may want to know the flight status given the flight number.
OK, now, given that you implement that, now you can look at which platforms will be calling this, as, one part of agile is not to over-develop, but in this case, if you have a business need to support mobile and desktop devices, then you should look at implementing this as a REST service, since that is the simplest solution for both to work with.
So the REST service solves the first story above.
Now, you will find that there are other specifics for each platform. For example, is there something on the phone that may already have the information, for example, did the traveller go to a trip site and already enter his info, then you may want to go there, assuming that the traveller is in the users contacts.
Or, if the user is just going to enter a flight number and that is it, then why not just do it as a webpage, as that is the simplest approach that supports both concepts. Then, if you have a url that supports GET, and outputs as HTML then you can easily display.
So, my first story was too simple, you may want to consider whether it is possible to return different types of data, so a user may want to have HTML, PDF, json or xml, but for each of these there should be a business need.
Unfortunately it is hard to answer your question as there are too many unknowns, which is why you are having a difficult time. If you ask the wrong question then you do have an epic, but if you can just break it down to a few simple stories then it becomes much easier to solve.
I would recommend the second option.
As you suggested, the first sounds like too much for a single story, and a story should always fit into a single iteration.
With the third option, the big problem is that you aren't delivering business value at the end of the story, which is generally a bad practice.
There are other ways you could split this work though. You could initially develop a very cut-down, barebones version which would work across all clients, and then refine each of them in subsequent stories.
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 3 years ago.
Improve this question
Most of you certainly use some kind of bugtracker. Maybe internally only, once a customer files a bug via email or phone you add a new ticket by yourself. Sometimes weekly project meetings can be great source of new tickets coming preferably in flavors of excel sheets that the PM on the other side of the table loves to maintain and chase after you.
The more advanced (and transparent) version: Allow the customer to file (and see the progress of) his bugs directly into you bugtracker. Systems like JIRA allow you to use profiles to have certain access rights, etc.
But now the question: The bug raised by a user not necessary translates into 1 bug in a specific module/method/EJB/class. The version of the (your) web application he uses does not translate into the version of the class that is causing the error. How you maintain the internal part of the ticket with all the nasty techy details and the same time the make-the-user-feel-good ticket (need more info, accepted, in progress,..) ? Creating 2 tickets for internal and external ? Link them ?
Any smart recipes to share ?
Separate your bug system from your customer support tracking system, and allow links between them.
Bugs can refer to zero, one or more customer support tickets.
Customer support tickets may refer to zero bugs (e.g. the customer's problem has nothing to do with your software), one bug (in case it's really a problem in your software) or more than one bug (shit happens).
Make queries like:
Which customers are waiting for a solution of bug X
Which customers are waiting on open critical bugs
Which bugs were already encountered by user Y
...
You will also notice that each database will have its own 'speed'. In my situation I have about 4 times more customer support calls than real bugs.
Most sensible way is to have two systems, or an alterantive mechanism for end users to submit bugs (via email). The main problem is not so much that a bug not necessarily translates into one method in a class, but mostly that if you have more than a handfull of users, peopel wont read existing bugs and think further than "button does not work".
If you isolate the real incident system (make it public, but read only), your staff can screen incoming bugs, make sur ethey are reproducable and have repro cases, check against existin bugs and in general have a clear bug once you enter it, and not soe hard to understand mess that may or may not ven make sense and be yet another entry of the same bug entered another 30 times already.
Each comment in JIRA has a "Viewable By" field that allows you to set the Group or Project Role to whom the comment is visible. You could use that to hide the "nasty techy details".
Alternatively you're probably on the right track when you say create two issues and link them. This has the added benefit of hiding your internal workflow from the customer.
One system for both (external) Help Desk and (internal) Issue Tracking. As long as you have complete control over visibility of tickets/issues, and can link between external/internal items, then this is no big deal.
Read more:
http://countersoft.com/downloads/whitepapers/Implementing_an_Issue_Management_Platform.pdf
Closed. This question needs to be more focused. It is not currently accepting answers.
Want to improve this question? Update the question so it focuses on one problem only by editing this post.
Closed 7 years ago.
Improve this question
I have been thinking about setting up some sort of library for all our internally developed software at my organisation. I would like collect any ideas the good SO folk may have on this topic.
I figure, what is the point in instilling into developers the benefits of writing reusable code, if on the next project the first thing developers do is file -> new due to a lack of knowledge of what code is already out there to be reused.
As an added benefit, I think that just by having a library like this would encourage developers to think more in terms of reusability when writing code
I would like to keep this library as simple as possible, perhaps my only two requirements being:
Search facility
Usable for many types of components: assemblies, web services, etc
I see the basic information required on each asset/component to be:
Name & version
Description / purpose
Dependencies
Would you record any more information?
What would be the best platform for this i.e., wiki, forum, etc?
What would make a software library like this successful vs unsuccessful?
All ideas are greatly appreciated.
Thanks
Edit:
Found these similar questions after posting:
How do you ensure code is reused correctly?
How do you foster the use of shared components in your organization?
Sounds like there is no central repository of code available at your organization. Depending on what you do this could be because of compatmentalization of the knowledge due to security restrictions, the fact that external vendor code is included in some/all of the solutions, or your company has not yet seen the benefits of getting people to reuse, refactor, and evangelize the benefits of such a repository.
The common attributes of solutions I have seen work at mutiple corporations are a multi pronged approach.
Buy in at some level from the management. Usually it's a CTO/CIO that the idea resonates with and they claim it's a good thing and don't give any money to fund it but they won't sand in your way if they are aware that someone is going to champion the idea before they start soliciting code and consolidating it somewhere.
Some list of projects and the collateral available in english. Seen this on wikis, on sharepoint lists, in text files within a source repository. All of them share the common attribute of some sort of front end search server that allows full text over the description of a solution.
Some common share or repository for the binaries and / or code. Oftentimes a large org has different authentication/authorization methods for many different environments and it might not be practical (or possible logistically) to share a single soure repository - don't get hung up on that aspect - just try to get it to the point that there is a well known share/directory/repository that works for your org.
Always make sure there is someone listed as a contact - no one ever takes code and runs it in production without at lest talking to the previous owner of it - and if you don't have a person they can start asking questions of right away then they might just go ahead and hit file->new.
Unsuccessful attributes I've seen?
N submissions per engineer per time period = lots of crap starts making it's way in
No method of rating / feedback. If there is no means to favorite/rate/give some indicator that allows the cream to rise to the top you don't go back to search it often because you weren't able to benefit from everyone else's slogging through the code that wasn't really very good.
Lack of feedback/email link that contacts the author with questions directly into their email.
lack of ability to categorize organically. Every time there is some super rigid hierarchy or category list that was predetermined everything ends up in "other". If you use tags or similar you can avoid it.
Requirement of some design document to accompany it that is of a rigid format the code isn't accepted - no one can ever agree on the "centralized" format of a design doc and no one ever submits when this is required.
Just my thinking.
Closed. This question is off-topic. It is not currently accepting answers.
Want to improve this question? Update the question so it's on-topic for Stack Overflow.
Closed 10 years ago.
Improve this question
A client using our system has requested that we store the SSNs/SINs of the end users in our database. Currently, we store minimal information about users (name, email address, and optionally, country), so I'm not overly concerned about a security breach - however, I have a suspicion there could be legal issues about storing SSNs and not taking "appropriate" measures to secure them (coming from Australia, this is my first encounter with them). Is this a valid concern?
I also read on the Wikipedia page about SINs (Canada's equivalent to SSNs) that it should ONLY be used when absolutely necessary and definitely shouldn't be used as a general identifier, or similar.
So, are there any potential legal issues about this sort of thing? Do you have any recommendations?
The baseline recommendation would be to:
Inform the user that you are storing their SSN before they use your site/application. Since the request appears to be to collect the information after the fact, the users should have a way to opt out of your system before they log in or before they put in their SSN
Issue a legal guarantee that you will not provide, sell, or otherwise distribute the above information (along with their other personal information of course)
Have them check a checkbox stating that they understand that you really are storing their SSNs
but the most important part would probably be:
Hire a lawyer well-versed with legal matters over the web
Funny thing about SSNs... the law that created them, also clearly defined what they may be used for (basically tax records, retirement benefits, etc.) and what they are not allowed to be used for - everything else.
So the fact that the bank requires your SSN to open a checking account, your ISP asks for it for high speed internet access, airlines demand it before allowing you on a plane, your local grocery/pub keeps a tab stored by your SSN - that is all illegal. Shocking, isn't it...
All the hooha around identity theft, and how easy it is thanks to a single, unprotected "secret" that "uniquely" identifies you across the board (not to mention that its sometimes used as authentication) - should never have been made possible.
Some good warning stated already here.
I'll just add that speaking of SIN (Canada's Social Insurance Number) codes, I believe it's possible to have collisions between a SIN and a SSN (in other words the same number, but two different people/countries). It shouldn't be a surprise since these are separate codification systems, but I somehow can imagine some doing data entry that may be inclined to stick a SIN into a SSN field and vis-versa (think international students in college/university as one instance - I was told by a DBA friend that he saw this happen).
A given information system may be designed to not allow duplicates, and either way, you can see why there might be confusion and data integrity issues (using a SSN column as a unique key? Hmm).
Way too many organizations in the USA use SSNs as unique identifiers for people, despite the well-documented problems with them. Unless your application actually has something to do with government benefits, there's no good reason for you to store SSns.
Given that so many organizations (mis)use them to identify people for things like credit checks, you really need to be careful with them. With nothing more than someone's name, address, and SSN, it's pretty easy to get credit under their name, and steal their identity.
The legal issues are along the lines of getting sued into oblivion for any leak of personal information that contains SSNs.
If it were me I'd avoid them like the plague, or figure out some very very secure way to store them. Additionally (not a legal expert by any extent but..) if you can put in writing somewhere that you are no way responsible if any of this gets out.
At a minimum, you want to be sure that SSNs are never emailed without some protection. I think the built-in "password to open" in Excel is enough, legally. I think email is the weakest link, at least in my industry.
Every now and then, there is a news item "Laptop Stolen: Thousands of SSNs Possibly Compromised." It's my great fear that it could be my laptop. I put all SSN containing files in a PGP-protected virtual drive.
You do have good security on your database, don't you? If not, why not?