Related
CONTEXT: We have a business customer to whom we need to send an encrypted file.
The business customer has send us a public key file that has a usage statement "Non commercial usage only". Our software is legit to encrypt stuff.
QUESTION: would it be illegal for us to encrypt stuff using client's public key
Best consult a lawyer. But a lot of those legal sounding notices are completely unenforceable, they're just there to scare people. In general, once someone sends something without a prior agreement, the receiver owns it entirely, as long as the sender has ownership of it. That is regardless of whether the sender changes their mind after the fact. Post conditions, which you can only read after receiving something even if they are sent at the same time, are not a prior agreement (you need the option to decline) before the transaction).
The important part is what rights the sender has. It's possible the sender doesn't have the rights to ask you to use the key as they asked you to. Again, a lawyer can clarify, I don't think you would be liable for that infraction, but the notice might be enough to mean you "should have known", and might have some liability.
Even better, ask your customer for clarification. I'm surprised you didn't do that in the first place. If they offer to indemnify you - that is, take responsibility for all liability you might incur by violating that notice - you should be in the clear, providing a lawyer agrees.
I'll say "lawyer" again, because the legal system takes about ten years full time study for a lawyer to just get started knowing it well enough to start practicing, and decades longer to get good at it. You can't expect anyone with a casual opinion about it to know enough.
Suppose we have an event and we want to prove that the event occurred after a particular date, we have a few easy ways of doing so. For example, one may just show a snapshot of a newspaper with a particular date and headline, indicating that the event is at least after that day. Or we could put in the ending stock price in a particular exchange of a particular date to say that it was after the end of trading hours of that day. This could be as fine grained to the second after the time when the exchange closed.
How to do the converse ? How can one say that an event occurred before a particular point of time ? One could depict large events (skyline of NYC to show various before or after WTC) and geological changes, but that is a very large-scale measure. Is there a much more fine-grained way to depict the fact, of the granularity of a few hours or days ?
Hash up the information you need to preserve (e.g. with a https://en.wikipedia.org/wiki/Merkle_tree) and publish the resulting hash value openly. This doesn't disclose any usable information, but if you later need to prove precedence, you can disclose the values you hashed up to show you had the information at that time.
I heard a story of AT&T paying for newspaper advertisements, long before computer security was mainstream, which disclosed a hash value. After a while the paper became worried that they were publishing mysterious advertisements every day that looked like secret codes and AT&T had to explain to the newspaper what the function of these were.
(A web search finds https://www.newscientist.com/article/mg13318103-800-technology-computer-fraudsters-foiled-by-the-small-ads/ including
Bellcore began running its advertisements in the New York Times in October
1991. They were interrupted for several months when newspaper employees
became suspicious of their cryptic contents. ‘Somebody said, ‘These look
like codes. You might be telling a terrorist to kill somebody,’ says Haber.
Fortunately for Bellcore, the Times’ computer correspondent persuaded the
newspaper to allow the advertisements back in.
Beware - article is buried in CSS and cookie notifications and inline ads)
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 5 years ago.
Improve this question
I am attempting to manage my projects a little better so I am looking at attempting to apply some of (eventually all) the features of scrum.
Looking at user stories specifically the high level format seems to be:
As a User I can Feature Description
or
Artifact is Doing Something
How would I write "Upgrade the Database"?
Is it simply Upgrade the Database?
I think I am being thrown off as there is no specific actor/customer and that the customer is the IT department.
AS A [person/role]
I NEED TO [do something]
SO THAT [provides business value].
For your example a user story might look like this:
AS A user of the XYZ application
I NEED TO get reports of ABC faster
SO THAT we can increase our conversion rates.
ACCEPTANCE CRITERIA - The database reliably completes transactions on average in 2 seconds.
I've added an acceptance criteria because without this you will never know when the job is done. Now at this point, you have a business case for upgrading the database. This story would be decomposed into a story where the role is the IT department or DBA, like so:
AS AN administrator for the database server
I NEED TO upgrade to the latest version of FancyDB 11.7
SO THAT we can improve the average transaction time for XYZ users to 2 seconds.
ACCEPTANCE CRITERIA - the new version starts successfully, the XYZ developers sign off on the test installation of 11.7, data migration is successful, we have cut over to the new db
When story decomposition is added to your box of tools, the story must start from where the user is a real part of the business, and the "so that" leads to a real business value. Then decompose the story into one or more stories in which internal users do things "so that" real users get the benefits in need.
Here are a couple of articles that talk about Story Decomposition:
http://jpattonassociates.com/the_shrinking_story/
http://old.cognitive-edge.com/wp-content/uploads/1999/11/56-1999-11-Paradox-of-Story.pdf
Scrum is not very prescriptive and there is nothing in Scrum that forces you to use User Stories for your Product Backlog Items (PBIs). You can definitely do Scrum without capturing requirements/features as user stories, user stories are just one way to do it. Actually, stories do work for many teams, especially web development teams, but this doesn't mean that they work in all cases and on every project (many projects are web development but not all, like in your case). There is no consensus about using stories.
That said, the recommended template for User Stories is actually As a <role>, I want to <action> so that <benefits>. I don't mean to be picky but, if you choose to use stories, I'd warmly suggest to use it as is, without removing any part. First, using a role do help (a same user/person can have several roles) to discover stories. Then specifying the benefits is really important to expose the business value of a story in order to prioritize them well. Regarding the value, you should think of it as end-user/customer ("put on customer glasses" --Mary Poppendieck). It is really not always that easy to express the benefits, but some tools might help and my preferred one is the 5 whys (which is used for root cause analysis).
In your case, this could lead to something like: As the IT department, I want the database to be upgraded so that users can benefits from the latest features of the application and [do a better job|have a better user experience] (not very satisfying though, use the 5 whys).
But personally I don't find that user stories are the best medium for technical tasks even if it is clearly possible to use them and if they have their strengths. Theoretically, stories capture the essence, not the details and should be a support for the discussion. I may be wrong but I don't find that technical tasks offer much room for discussion and creativity. So, depending on who will read them, what the should convey, I might use them or not. Another option could be to mix stories with another formalism for your PBIs. As I said, the point is not to use stories, the point is to have a list of prioritized and estimated items.
Upgrade the database may be one of the tasks involved in implementing another story that brings direct value to the user, for example I as a user can add a new foo to my bar.
If adding a foo to a bar requires a database upgrade behind the scenes, then you would include that work in implementing that user story.
User stories are worded this way to help ensure that any work directly benefits the end user in some way.
This gets to the forefront of why user stories are so great.
What benefit does upgrading your database give to the end user? None? Then don't spend the time and money doing it. Spend that time and money providing something that will give value to your end user.
If it does? Then think about it the other way. Maybe you can only implement a new feature when you have version x of your database software? In the dependency of the story, you could mention that database upgrade required to provide this feature.
tl;dr Don't just upgrade for the sake of it. Make sure upgrading adds tangible value to your customers.
Generally, technical tasks in the PB are frowned upon because they very rarely directly deliver business value to the customer. That's why User Stories are popular, because they force you to think about the business value of the story, and who it's being delivered to.
So, why are you upgrading the database? Can you identify business value in upgrading it, and why should the Product Owner agree to let you upgrade the database instead of building new features?
Is it because of a new feature that will make it possible or make it easier to do something in your application? In that case, that something should be the PB item, and the database upgrade should be a task within that story. If you already have stories on the PB that would benefit from the upgrade, then you should increase the estimates for one or more of those stories, and add the upgrade as a technical task to the story.
Is it because the vendor of the database is cutting off an old version from support? In that case you could have the upgrade as the story; something like, "As the department manager, I want to be sure that we have support for all of the software so that the continuity of the business isn't at risk if something goes wrong". Even that's pushing it, though. Generally, this kind of reason isn't really part of a project, unless the project has been going on so long the system software goes off support.
Is it for performance? Then the story should be about some aspect of the performance of the application that needs to be improved to deliver business value. Something like, "As a CSR I need to be able to retrieve customer information in a reasonable time so that customers on the phone are satisfied with our service". Then the upgrade becomes a task under that story.
Is it for some totally technical reason? If you can't identify how the upgrade is going to deliver business value, then why would you do it? Why would the Product Owner select it for a Sprint?
It's simply "Upgrade the Database" or maybe "When the new version is installed, there must be a way to migrate the existing database". If you already know more details about this step, then include them. But the story mostly exists to make sure something isn't forgotten; it's not to be detailed.
Later, when you get to implement this story, you can flesh it out (which tables, do we need one or more backups, is there a fall back scenario, etc).
OTOH, if the project is more complex, this can become a "tag", like a post-it notice which must be attached to many stories. That means you must include this as a "sub story" to all stories which change the database. As you can see, these "project-spanning stories" are a bit hard to track with agile methods.
Infrastructure stories do not need to follow the prescribed story template. Just write down what needs to be done and estimate accordingly
How about:
As the application support person I want to be on the latest version of database because it is more reliable / more secure / whatever.
You could even phrase refactoring like that:
As the application developer I want all the data classes in one module so that I can add new fields to the app very quickly.
Who benefits
What you want to do
What the benefit is
Ideally you don't want all the stories to have 1 be developers, but a few make sense (sharpening your ax instead of cutting down trees and all that).
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
The question is quite generic. What are the points that should be kept in mind to identify a valid use case? How to approach a use case?
A use case identifies, with specificity, a task or goal that users will be able to accomplish using a program. It should be written in terms that users can understand.
Wikipedia's description is overly formal. I'll dig through my other texts shortly.
In contrast, the original wiki's article is much more accessible.
An early article by Alastair Cockburn, cited positively by The Pragmatic Programmer, contains a good template.
This question, from just a few days ago, is very closely related, but slightly more specific.
The definition of use case is simple:
An actor's interactions with a system to create something of business value.
More formally:
a sequence of transactions performed
by a system that yield a measurable
set of values for a particular actor.
They're intended to be very simple: Actor, Interaction, Value. You can add some details, but not too many.
Using use cases is easy. Read this: http://www.gatherspace.com/static/use_case_example.html
The biggest mistake is overlooking the interaction between actor and system. A use case is not a place to write down long, detailed, technical algorithm designs. A use case is where an actor does something.
People interact with systems so they can take actions (place orders, approve billing, reject an insurance claim, etc.) To take an action, they first make a decision. To make a decision, they need information
Information
Decision
Action
These are the ingredients in the "Interaction" portion of a use case.
A valid use case could describe:
intended audience / user
pre-requisites (ie must have logged in, etc)
expected outcome(s)
possible points of failure
workflow of user
From Guideline: Identify and Outline Actors and Use Cases by the Eclipse people:
Identifying actors
Find the external entities with which
the system under development must
interact. Candidates include groups of
users who will require help from the
system to perform their tasks and run
the system's primary or secondary
functions, as well as external
hardware, software, and other systems.
Define each candidate actor by naming
it and writing a brief description.
Includes the actor's area of
responsibility and the goals that the
actor will attempt to accomplish when
using the system. Eliminate actor
candidates who do not have any goals.
These questions are useful in
identifying actors:
Who will supply, use, or remove
information from the system?
Who will
use the system?
Who is interested in a
certain feature or service provided by
the system?
Who will support and
maintain the system?
What are the
system's external resources?
What
other systems will need to interact
with the system under development?
Review the list of stakeholders that
you captured in the Vision statement.
Not all stakeholders will be actors
(meaning, they will not all interact
directly with the system under
development), but this list of
stakeholders is useful for identifying
candidates for actors.
Identifying use cases
The best way to find use cases is to
consider what each actor requires of
the system. For each actor, human or
not, ask:
What are the goals that the actor will
attempt to accomplish with the system?
What are the primary tasks that the
actor wants the system to perform?
Will the actor create, store, change,
remove, or read data in the system?
Will the actor need to inform the
system about sudden external changes?
Does the actor need to be informed
about certain occurrences, such as
unavailability of a network resource,
in the system?
Will the actor perform
a system startup or shutdown?
Understanding how the target
organization works and how this
information system might be
incorporated into existing operations
gives an idea of system's
surroundings. That information can
reveal other use case candidates.
Give a unique name and brief
description that clearly describes the
goals for each use case. If the
candidate use case does not have
goals, ask yourself why it exists, and
then either identify a goal or
eliminate the use case.
Outlining Use Cases
Without going into details, write a
first draft of the flow of events of
the use cases identified as being of
high priority. Initially, write a
simple step-by-step description of the
basic flow of the use case. The
step-by-step description is a simple
ordered list of interactions between
the actor and the system. For example,
the description of the basic flow of
the Withdraw Cash use case of an
automated teller machine (ATM) would
be something like this:
The customer inserts a bank card.
The system validates the card and prompts
the person to enter a personal
identification number (PIN).
The customer enters a PIN.
The system
validates the PIN and prompts the
customer to select an action.
The customer selects Withdraw Cash.
The system prompts the customer to choose
which account.
The customer selects
the checking account.
The system
prompts for an amount.
The customer
enters the amount to withdraw.
The
system validates the amount (assuming
sufficient funds), and then issues
cash and receipt.
The customer takes the cash and receipt, and then
retrieves the bank card.
The use case ends.
As you create this step-by-step
description of the basic flow of
events, you can discover alternative
and exceptional flows. For example,
what happens if the customer enters an
invalid PIN? Record the name and a
brief description of each alternate
flow that you identified.
Representing relationships between
actors and use cases
The relationship between actors and
use cases can be captured, or
documented. There are several ways to
do this. If you are using a use-case
model on the project, you can create
use-case diagrams to show how actors
and use cases relate to each other.
Refer to Guideline: Use-Case
Model for more information.
If you are not using a use-case model
for the project, make sure that each
use case identifies the associated
primary and secondary actors.
Closed. This question does not meet Stack Overflow guidelines. It is not currently accepting answers.
We don’t allow questions seeking recommendations for books, tools, software libraries, and more. You can edit the question so it can be answered with facts and citations.
Closed 2 years ago.
The community reviewed whether to reopen this question 11 months ago and left it closed:
Original close reason(s) were not resolved
Improve this question
Is it even possible to perform address (physical, not e-mail) validation? It seems like the sheer number of address formats, even in the US alone, would make this a fairly difficult task. On the other hand it seems like a task that would be necessary for several business requirements.
Here's a free and sort of "outside the box" way to do it. Not 100% perfect, but it should reject blatantly non-existent addresses.
Submit the entire address to Google's geocoding web service. This service attempts to return the exact coordinates of the location you feed it, i.e. latitude and longitude.
In my experience if the address is invalid you will get a result of 602 from the service. There's definitely a possibility of false positives or false negatives, but used in conjunction with other consistency checks it could be useful.
(Yahoo's geocoding web service, on the other hand, will return the coordinates of the center of the town if the town exists but the rest of the address is bogus. Potentially useful as long as you pay close attention to the "precision" field in the result).
There are a number of good answers in here but most of them make the assumption that the user wants an "API" solution where they must write code to connect to a 3rd-party service and/or screen scrape the USPS. This is all well and good, but should be factored into the business requirements and costs associated with the implementation and then weighed against the desired benefits.
Depending upon the business requirements and the way that the data is received into the system, a real-time address processing solution may be the best bet. If a real-time solution is required, you will want to consider the license agreement and technical limitations of the Google Maps/Bing/Yahoo APIs. They typically limit the number of calls you can make each day. The USPS web tools API is the same in additional they restrict how/why you can use their system and how you are allowed to use the data thereafter.
At the same time, there are a handful of great service providers that can easily process a static list of addresses. Essentially, you give the service provider a CSV file or Excel file, they clean it up and get it back to you. It's a one-time deal with no long-term commitment or obligation—usually.
Full disclosure: I'm the founder of SmartyStreets. We do address verification for addresses within the United States. We are easily able to CASS certify a list and we also offer a address verification web service API. We have no hidden fees, contracts, or anything. You use our service until you no longer need it and you can walk away. (Unlike cell phone companies that require a contract.)
USPS has an address cleaner online, which someone has screen scraped into a poor man's webservice. However, if you're doing this often enough, it'd be a better idea to apply for a USPS account and call their own webservice.
I will refer you to my blog post - A lesson in address storage, I go into some of the techniques and algorithms used in the process of address validation. My key thought is "Don't be lazy with address storage, it will cause you nothing but headaches in the future!"
Also, there is another StackOverflow question that asks this question entitled How should international geographic addresses be stored in a relational database.
In the course of developing an in-house address verification service at a German company I used to work for I've come across a number of ways to tackle this issue. I'll do my best to sum up my findings below:
Free, Open Source Software
Clearly, the first approach anyone would take is an open-source one (like openstreetmap.org), which is never a bad idea. But whether or not you can really put this to good and reliable use depends very much on how much you need to rely on the results.
Addresses are an incredibly variable thing. Verifying U.S. addresses is not an easy task, but bearable, but once you're going for Europe, especially the U.K. with their extensive Postal Code system, the open-source approach will simply lack data.
Web Services / APIs
Enterprise-Class Software
Money gets it done, obviously. But not every business or developer can spend ~$0.15 per address lookup (that's $150 for 1,000 API requests) - a very expensive business model the vast majority of address validation APIs have implemented.
What I ended up integrating: streetlayer API
Since I was not willing to take on the programmatic approach of verifying address data manually I finally came to the conclusion that I was in need of an API with a price tag that would not make my boss want to fire me and still deliver solid and reliable international verification results.
Long story short, I ended up integrating an API built by apilayer, called "streetlayer API". I was easily convinced by a simple JSON integration, surprisingly accurate validation results and their developer-friendly pricing. Also, 100 requests/month are entirely free.
Hope this helps!
I have used the services of http://www.melissadata.com Their "address object" works very well. Its pricey, yes. But when you consider costs of writing your own solutions, the cost of dirty data in your application, returned mailers - lost sales, and the like - the costs can be justified.
For us-based address data my company has used GeoStan. It has bindings for C and Java (and we created a Perl binding). Note that it is a commercial product and isn't cheap. It is quite fast though (~300 addresses per second) and offers features like CASS certification (USPS bulk mail discount), DPV (Delivery point verification) flagging, and LON/LAT geocoding.
There is a Perl module Geo::PostalAddress, but it uses heuristics and doesn't have the other features mentioned for GeoStan.
Edit: some have mentioned 'doing it yourself', if you do decide to do this, a good source of information to start with is the US Census Tiger Data Set, which contains a lot of information about the US including address information.
As seen on reddit:
$address = urlencode('1600 Pennsylvania Avenue, Washington, DC');
$json = json_decode(file_get_contents("http://where.yahooapis.com/geocode?q=$address&flags=J"));
print_r($json);
Fixaddress.com service is available that provides following services,
1) Address Validation.
2) Address Correction.
3) Address spell correcting.
4) Correct addresses phonetic mistakes.
Fixaddress.com uses USPS and Tiger data as reference data.
For more detail visit below link,
http://www.fixaddress.com/
One area where address lookups have to be performed reliably is for VOIP E911 services. I know companies reliably using the following services for this:
Bandwidth.com 9-1-1 Access API MSAG Address Validation
MSAG = Master Street Address Guide
https://www.bandwidth.com/9-1-1/
SmartyStreet US Street Address API
https://smartystreets.com/docs/cloud/us-street-api
There are companies that provide this service. Service bureaus that deal with mass mailing will scrub an entire mailing list to that it's in the proper format, which results in a discount on postage. The USPS sells databases of address information that can be used to develop custom solutions. They also have lists of approved vendors who provide this kind of software and service.
There are some (but not many) packages that have APIs for hooking address validation into your software.
However, you're right that its a pretty nasty problem.
http://www.usps.com/ncsc/ziplookup/vendorslicensees.htm
As mentioned there are many services out there, if you are looking to truly validate the entire address then I highly recommend going with a Web Service type service to ensure that changes can quickly be recognized by your application.
In addition to the services listed above, webservice.net has this US Address Validation service. http://www.webservicex.net/WCF/ServiceDetails.aspx?SID=24
We have had success with Perfect Address.
Their database has all the US street names and street number ranges. Also acts as a pretty decent parser for free-form address fields, if you are lucky enough to have that kind of data.
Validating it is a valid address is one thing.
But if you're trying to validate a given person lives at a given address, your only almost-guarantee would be a test mail to the address, and even that is not certain if the person is organised or knows somebody at that address.
Otherwise people could just specify an arbitrary random address which they know exists and it would mean nothing to you.
The best you can do for immediate results is request the user send a photographed / scanned copy of the head of their bank statement or some other proof-of-recent-residence, because at least then they have to work harder to forget it, and forging said things show up easily with a basic level of image forensic analysis.
There is no global solution. For any given country it is at best rather tricky.
In the UK, the PostOffice controlls postal addresses, and can provide (at a cost) address information for validation purposes.
Government agencies also keep an extensive list of addresses, and these are centrally collated in the NLPG (National Land and Property Gazetteer).
Actually validating against these lists is very difficult. Most people don't even know exactly how their address as it is held by the PostOffice. Some businesses don't even know what number they are on a particular street.
Your best bet is to approach a company that specialises in this kind of thing.
Yahoo has also a Placemaker API. It is good only for locations but it has an universal id for all world locations.
It look that there is no standard in ISO list.
You could also try SAP's Data Quality solutions which are available in both a server platform is processing a large number of requests or as an embeddable SDK if you wanted to run it in process with your application. We use it in our application and it's very robust and scalable.
NAICS.com is coming out with an API that will add all kinds of key business data including street address. This would happen on the fly as your site's forms are processed. https://www.naics.com/business-intelligence-api/
You can try Pitney Bowes “IdentifyAddress” Api available at - https://identify.pitneybowes.com/
The service analyses and compares the input addresses against the known address databases around the world to output a standardized detail. It corrects addresses, adds missing postal information and formats it using the format preferred by the applicable postal authority. I also uses additional address databases so it can provide enhanced detail, including address quality, type of address, transliteration (such as from Chinese Kanji to Latin characters) and whether an address is validated to the premise/house number, street, or city level of reference information.
You will find a lot of samples and sdk available on the site and i found it extremely easy to integrate.
For US addresses you can require a valid state, and verify that the zip is valid. You could even check that the zip code is in the right state, but beyond that I don't think there are many tests you could run that wouldn't provide a lot of false negatives.
What are you trying to do -- prevent simple mistakes or enforcing some kind of identity check?