The variables that insurers use to calculate the price of a policy are, for the most part, deemed fair by customers, but they are struggling with rising costs, a recent survey said.

Most Americans think insurance prices are calculated fairly, but many find paying it a challenge: survey

Best Cheap Car Insurance Companies in Chesapeake, Va. In Chesapeake, we recommend Virginia Farm Bureau, State Farm, Erie, Auto-Owners and Travelers for car insurance. These companies have rates that are lower than average for both minimum and full coverage ...

Cheap Car Insurance in Chesapeake, Va.

If your small business uses a vehicle like a car, truck or van for work purposes, you need a commercial auto insurance policy. Your personal car insurance won’t cover work-related accidents. We analyz

Best Commercial Auto Insurance Companies Of November 2023

Slide Insurance, a 2-year-old insurtech startup based in Tampa, announced it has acquired renewal rights for 86,000 Florida homeowners and condo owners policies from Farmers. Farmers

Slide insurance to pick up 86K farmers home insurance policies in Florida

An in-depth review of American Family car insurance, including coverage options, pricing, customer satisfaction and how AmFam compares to other insurance companies.

American Family car insurance review 2023

"The best tool consumers have to address the coverage and pricing concerns is to shop around." If car owners do have trouble finding insurance coverage they want or can afford, Davis says there are still ways to get insured. "Look into increasing your ...

Insurance Commissioner's Office urges Kia and Hyundai owners to shop around for coverage

Auto insurance rates are rapidly rising, outpacing inflation. Consumers have options and strategies to help with bearing the cost.

Auto Insurance Prices Are Rising. Here’s What You Can Do To Save Money

It’s one of the most common selling points of insurance companies on TV commercials. If you bundle the coverage of your home, auto, boat or life into one policy, you can save money.

There are great savings in bundling your insurance, but not so much in Florida

Auto insurance can provide coverage for a stolen car, but only if the right protections are in place before the theft occurs. Here's what you need to know.

Will Auto Insurance Cover You if Your Car Is Stolen?

Get the most recent info and news about Auto-Owners Insurance on HackerNoon, where 10k+ technologists publish stories for 4M+ monthly readers.

Owners Insurance Company provides insurance services. The Company offers car, life, home, business, and casualty insurance services. Owners Insurance serves customers throughout the United States.

Auto-Owners Insurance

Welcome to the dawn of the self-driving car era, and a subsequent emerging challenge: how to insure them. For the last two decades, improvements to sensor technology & its gradual adoption into both commercial and domestic sectors has drastically improved the affordability of manufacturing. This cheaper technology eventually made its way into the hands of automakers, and is the genesis of self-driving technology. To understand this and how to insure its additional risks, we must first look at the technology itself. Technology & Viability Advanced technology provide the 'brains' for self-driving vehicles Originally, the largest technical limitation to self-driving cars was the significant processing power required to synthesize the data from so many sensors. However, recent advancements in cloud systems, computer chip design, and AI has enabled much smaller computers to monitor real-time data, take action, and provide services autonomously. This data gold rush has driven companies like Tesla, Waymo, and Luminar into a race to create commercially viable self-driving vehicle systems. In contrast to the cloud systems and AI, many sensor technologies are mature in their development if not application. Many of these companies are making the push to create self-driving systems that use an array of sensors to feed data into a computer that autonomously decides on behalf of the driver. These sensors include cameras (which detect and identify objects via an AI called computer vision), ultrasonic, radar, and Lidar (which is better at detecting and mapping short and long range distance). In contrast to the cloud systems and AI, many sensor technologies are mature in their development if not application. For example, the vast majority of Fortune 500 companies are still undergoing digital transformation incorporating cloud and AI technologies into their operating models. Whereas sensor tech like Lidar and radar has been used for decades in military and commercial applications. What this means is that vehicles like Tesla which rely heavily on cameras/computer vision, radar, and ultrasonic sensors are still years from maturing their technology and having fully autonomous self-driving capabilities. Companies like Luminar (which provides the sensors) with proven lidar systems are beyond the price range of the average consumer, making them uneconomical for self-driving applications. Unless industry makes drastic advancements on cheaper lidar versions, these systems will not be viable at scale except perhaps in commercial applications like driverless delivery. What does this mean for insurance? When fully autonomous vehicles reach saturation, the reduction in risk will drive the price of auto policies down. Yet, the increase in value of autonomous vehicles will require owners to purchase more coverage. Over time, this will create a major problem for state insurance regulators. The high purchase price of fully autonomous vehicles will exclude many low income auto owners from adequately insuring their vehicles, potentially resulting in an overall increased cost of coverage. State regulators will also have to set new minimums on auto coverage to address the increased value of self-driving systems included in the overall cost of the average vehicle. Ultimately, state legislatures will have to be cautious that they do not create a system that imposes more costs on the less financially abled. The intersection between vehicles with greater connectivity and cyber security will become increasingly important over the next decade. Cyber crimes will continue, and it is only a matter of time before cyber criminals hack into these systems/vehicles. The purpose of these hacks may vary, but the use of ransomware, disabling the vehicle until the owner pays the ransom, will make up a significant number of these cyber security incidents. This will lead to insurers either including, or offering supplemental coverage options for cyber to consumers as a part of auto insurance. Self-driving cars will require changes to not just auto insurance, but the new infrastructure being built to support them. Self-driving vehicles will pose unique opportunities and challenges for claims professionals. On one hand, the plethora of sensor data will make it easier to determine the accident timeline and which driver(s) are at fault. On the other insurance companies will have to develop the capacity to analyze this sensor data, thus imposing an additional expense on the insurer. The new reliance on vehicle sensor data will see the claims field shift to a heavier IT emphasis, with new software augmenting much of what a claim professional does. Eventually, determining payouts and accident faults will be entirely automated under the belief that ‘data does not lie.’ As claims are on the tail-end of the insurance life-cycle, self-driving technology will have little to no effect in the immediate future. Within the next decade, though, claims will undergo a radical shift because of this new technology. Self-driving cars will require changes to not just auto insurance, but the new infrastructure being built to support them. In commercial applications like increasingly popular last mile delivery services, driverless delivery will dramatically cut labor expenses. The cost for insurance however will increase in the short run. Without a driver involved, there is an ambiguity of who handles goods delivered. The retailer, the storage facility, the delivery service, or the customer? This increases the liability for lost, damaged, or stolen packages. Storefronts and storage facilities being repurposed for last mile delivery are especially exposed to extra risks like theft, property damage, spoilage of food products, and fire. Thinking about insurance holistically (auto, property, general liability, etc.) will become increasingly important in the era of the self-driving vehicles. Self-driving vehicles are coming into existence because consumers want even greater convenience. And to stay relevant, insurance professionals will need to match that level of convenience. On the technology side, regardless of the flavor of the sensor, companies on the cutting edge of technology and manufacturing processes are still 3-10 years away from making a commercially viable fully autonomous vehicle, plus an additional 4-10 years after commercial viability before enough companies and segments of the population adopts these vehicles to make a significant impact on insurers. Whether through embedded insurance, better sales technologies, or new product offerings like auto-cyber, the next decade will see major innovation within the insurance industry. Special thank you to the co-author of the article, Elisha Cheng . Elisha is the COO of ReFocus AI , an enterprise AI-powered sales plugin for insurance professionals. As a recent graduate, he co-founded EPort an international import export company out of Southern China which he sold to East West Trading Co. He holds a bachelor's degree from University of California, Riverside in International Political Economy. Elisha currently resides in Sacramento, California. Also published on: https://blog.refocusai.com/insurance-and-self-driving-cars/

How Self-Driving Cars Will Change the Auto Insurance Industry

I recently gave a talk at React Amsterdam on running GraphQL at scale , covering some different use cases and techniques that come up in production. One such scenario was related to authorization in a cascading manner using multiple data sources which motivated this article. This is a bit of an advanced subject so if you’re just getting started, I recommend starting with more introductory information here and here . Granting access to data in can be a tricky subject, with multiple strategies and starting to pop up as the technology becomes more widely adopted. gives you powerful techniques to enforce different authorization controls for use cases like: GraphQL emerging best practices GraphQL Completely public API Private and Public access to sections of an API Private and Public records, checked at runtime on fields One or more users can write/read to a record(s) One or more groups can write/read to a record(s) Everyone can read but only record creators can edit or delete Fundamentally when implementing access control in any system, some metadata must exist about who or what can access a resource. The classical way of defining this is with Butler Lampson’s where granted permissions are the intersection of rows and columns comprised of resources and actors (which can be users, roles, groups, etc.). When interacting directly with a database this “authorization metadata” many times is a part of that system and the access control is performed at connection time or runtime. In a service architecture fronted by a GraphQL API, a level of indirection exists where database interactions are happening on behalf of the caller. GraphQL also allows authorization to take place at the field level for partial results to be returned on a query. While this may seem daunting at first, in fact you end up with powerful controls which allow you to store authorization data on a resource, in a separate data source, or mix/match for combinations of controls. You can even cascade checks at different levels to meet your unique business needs. Access Control Matrix This article demonstrates how you can use GraphQL techniques for authorization using , however these strategies can be applied to custom GraphQL solutions as well. While AppSync has a first class concept called a “data source”, the generalization can be applied to GraphQL resolvers as the location they use to fetch data. Using the above description on performing access control checks, you can see in the below diagram how this can be done by storing the metadata for authorization on a resource (the “author” column of a database record) and threading identity information of the caller through a request to perform a conditional check when a GraphQL resolver is invoked. Read more . AWS AppSync here While many scenarios for access control can use a single data source, some authorization use cases require the use of multiple data sources. For instance in AppSync you might do this because you want to first perform some logic in a Lambda function before fetching or writing data to a DynamoDB table, or it could be to first perform a lookup such as allowing only people who you are “friends” with to read your data (1:many checks). GraphQL makes this possible by using resolvers on your fields and walking the application graph, fetching data from different data sources and performing authorization checks where appropriate. You can use this technique along with the for many advanced scenarios. For example while fine grained access controls allow you to perform conditional logic inside the resolver, such as user or group checks, nested resolvers and aggregated context allow you to perform this logic using results from the parent object. To demonstrate this we’ll start with a simple use case. built-in fine grained access controls of AWS AppSync Nested resolvers In the , authorization metadata is stored directly on the resource (such as an attribute for an item in a table called “owner”). For demonstrative purposes, suppose these were separate tables and I want to read data in a “Data” table but first run an authorization check against data in an “Auth” table which lists who is the “Owner” of an item in the “Data” table. Only the “Owner” listed in the “Auth” table has rights to read the corresponding information in the “Data” table (the IDs in each table have an implicit association). The table layout is in the below image with some records and pseudocode of how you would want the logical check to work. AWS AppSync fine grained access control examples In this layout, user Nadia would have access to items 1&3 in the “Data” table while Shaggy has access to item 2. To use separate data sources, you can “nest” the data you want to retrieve inside a GraphQL type that gets your authorization metadata from a separate data source and essentially walk the object graph in your query. An example GraphQL schema to perform this nesting is below. type AuthCheckData { id: ID! data: Data } type Data { id: ID! title: String content: String } type Query { getData(id:ID!): AuthCheckData } In the above GraphQL schema the query will invoke a resolver against the and return a type . Then a resolver set on the field will have access to the returned data of it’s parent field to perform authorization checks. A diagram of the flow is below. getData Auth table AuthCheckData data:Data The resolver request template is fairly standard — it actually only needs to run a against the Auth DynamoDB data source with no other arguments: getData GetItem {"version": "2017-02-28", "operation": "GetItem", "key": { "id": $util.dynamodb.toDynamoDBJson($ctx.args.id), } } The response template is just passing through the data: $util.toJson($context.result) Since the whole result is being returned, any of the attributes from the table (in this case ) are returned and available for the child fields to use in a resolver template via the object (aliased as ). Auth Owner $context.source $ctx.source This is where things get interesting. Set a resolver on and again use a but now use the ID from the parent with in the resolver request template: data: Data GetItem, $ctx.source.id { "version" : "2017-02-28", "operation" : "GetItem", "key" : { "id" : { "S" : "${ctx.source.id}" } } } This is important because you’re essentially ensuring that the authorization metadata from the parent check matches the data you’re performing validation against, which just a single argument passed into your GraphQL query. Now you can filter the results in the response template for the resolver to only return values from the Data table if the (available in from the Auth table) is equal to the current user, as seen in the below resolver response template: data: Data Owner $context.source.Owner #if ($context.source.Owner == $context.identity.username) $util.toJson($ctx.result) #else $utils.unauthorized() #end At this point a GraphQL query of or can be run and if Nadia is logged in she’ll see her data. The query would look similar to this: getData(id:1) getData(id:3) query {getData(id:1){data{idtitlecontent}}} If Nadia runs a query of she’ll get an unauthorized message, but if Shaggy runs that query he’ll see the data as he’s listed as the owner in the Auth table. getData(id:2) AWS Lambda Authorizer Suppose you have more complex business logic for authorization, token validation, or you need to interact with a data source that AWS AppSync does not yet support. However, you want to return results from an DynamoDB table if an authorization check passes. You can use the same architecture as before but this time, have the resolver use an AWS Lambda function for the first layer of access to perform authorization and pass the results to your DynamoDB resolver. getData() To set this up use the same schema from earlier, but now add a new AppSync data source of an AWS Lambda function. If you’re not familiar with setting up and using . You’ll need to create the Lambda function first before using it with AppSync, for this example use the below function written in Node.JS: Lambda functions in AWS AppSync take a look at this tutorial first 'use strict'; exports.handler = (event, context, callback) => {console.log(event); let valid = allow(event);  
  
switch(event.field) {  
    case "getData":  
        var id = event.arguments.id;  
        if (valid) {  
            callback(null, {id: event.arguments.id});  
        } else {  
          let result = {};  
          result.errorMessage = "Error with the authorization";  
          result.errorType = "AUTHORIZATION\_ERROR";  
          callback(null, result);  
        }  
        break;  
    case "addData":  
        // Write similar authorization check here  
        callback(null, event.arguments);  
        break;  
    default:  
        callback("Unknown field, unable to resolve" + event.field, null);  
        break;  
} }; function allow(event) {const allowedKeys = ["abcdef", "ghijkl"];const allowedUsers = ["Nadia", "Caesar"];const allowedIps = ["192.168.0.1"]; if (allowedUsers.includes(event.identity.username))  
  return true;  
else if (allowedKeys.includes(event.request.headers.x-api-key))  
  return true;  
else if (allowedIps.includes(event.identity.sourceIp))  
  return true;  
else  
  return false; } The code above has an function that authorizes requests from a set of Users, API Keys, or IP Addresses. If any of them is a match from then authorization will be allowed. For instance if a client passes in a valid API Key, is in a whitelisted IP address list, or is one of a valid list of users then access will be granted. . If the client calling your GraphQL API doesn’t pass these checks then the Lambda will return an of . This is a fictitious example, but the point is that you can perform your custom authorization logic in your Lambda and cascade the data fetching invocation to other resolvers, which you’ll do next, without needing to put everything in a Lambda function. allow() You can see a full list of identity object threaded into the context object of an AppSync request here errorType AUTHORIZATION_ERROR Change the resolver on to use this AWS Lambda data source. The resolver request template needs to specify the GraphQL field being invoked, and also the identity and arguments: getData(): AuthCheckData {"version" : "2017-02-28","operation": "Invoke","payload": {"field": "getData","identity" : $utils.toJson($context.identity),"arguments":  $utils.toJson($context.arguments)}} However, unlike with the previous scenario where you passed down from the parent and did the authorization check in the child, with the Lambda returning the directly you can have your check on the resolver response template of the itself: $context.source.Owner result.errorType getData() #if ($context.result.get("errorType") == "AUTHORIZATION_ERROR")$util.unauthorized()#else$util.toJson($context.result)#end With a pattern like this you’re essentially “wrapping” all of the auth logic in the parent resolver so that the child resolver strictly focuses on data fetching and the separation of concerns is cleaner. Now the resolver request template on the field still does a lookup with the data source on the “Data” table using (since that’s what the Lambda returned in a valid authorization case) but the response template is simply: getData() AuthCheckData:data $ctx.source.id $util.toJson($ctx.result) The nice thing about this pattern is the parent resolver, , essentially “wrapped” the authorization logic and only invoked the child to return data if it passed a validity check. getData() Only let my friends read Another very common use case with authorization is where an individual entity will allow several other entities to access a resource in a 1:MANY manner. In social media applications this might be stated as “only allow Nadia’s friends to see her information”. The typical way that you model this using DynamoDB would be to have a “friendship table” that does the check before accessing the actual record. The friendship table would have a composite key comprised of the user ID and the friend ID. Create a “Friend” table in DynamoDB with a Primary Key of and a Sort Key of . Use strings for both. For convenience, also add a column of so that you can quickly switch of someone is no longer a friend (you could always delete the row too). Add this table as an AWS AppSync data source and edit your schema to have a query type of like below. Username Friend Valid friendGetData(id:ID!, friend:String!) type Query {getData(id: ID!): AuthCheckDatafriendGetData(id: ID!, friend: String!): AuthCheckData} The idea is a user can access a record if they happen to be friends with someone. To keep things simple we will pass in an ID of a record we wish to receive from the same table as before, but first do a friendship check against the new table. The request template for looks like the following: Data Friend friendGetData() {"version" : "2017-02-28","operation" : "GetItem","key" : {"Username" : { "S" : "${ctx.identity.username}" },"Friend" : { "S" : "${ctx.args.friend}" }}} This will return the attribute of from your table if you are a friend with the person. Like the last example, we’ll keep the authorization logic in the top level resolver’s response template to keep responsibilities separate. However unlike the last two cases, the “ ” table doesn’t have a primary key of “ID” so it won’t get automatically passed in the source object. Since we want to use the passed as an argument for a key lookup in the “ table when the child resolver is invoked, we also add this to the context object in the response template: Valid Friend id Data” $util.qr($context.result.put("id", "$context.arguments.id"))#if ($context.result.get("Valid") == "TRUE")$util.toJson($context.result)#else$util.unauthorized()#end Now we can access the as in the other examples through . If you run a query: id $context.source.id query friend {friendGetData(id:1 friend:"Nadia"){data{titlecontent}}} This runs successfully for logged in users whom Nadia is friends with. Mutations All of the examples so far have covered queries as conceptually, I wanted to demonstrate the controls that GraphQL gives you to manipulate your authorization schemes. You can apply these techniques to mutations as well, however there will be a subtle difference in that you might need to perform conditional checks in the request pipeline of your resolver rather than a filter on the response. The way that you control this will be very specific to the data source implementation that is used for your mutation. For example, AWS AppSync supports several data sources including Amazon DynamoDB which supports that can be evaluated by the database engine itself. If you think back to the patterns shown in this article, one showed how you can pass authorization metadata from the parent to the child and make a decision vs. “wrapping” all of the authorization decisions in the parent resolver. If your design is using the first technique then you won’t be able to apply authorization logic on the response of a database operation as the write would have already happened. Instead, you’ll need to use that database engine’s execution criteria along with the metadata passed from the parent resolver. In a DynamoDB resolver with AppSync you would add something similar to the following to your resolver request template: condition expressions "operation" : "UpdateItem","condition" : {"expression" : "contains(Edit,:canEdit)","expressionValues" : {":canEdit" : { "S" : "${context.source.canedit}" }}} The above uses the owner from the parent resolver and at runtime if an attribute of was passed down to the child resolver. . Of course it may be the case that your database implementation doesn’t support these capabilities, isn’t performant for these types of runtime evaluations, or your schema design is simply to separate the authorization logic into the parent in which case the other method can still be used. canedit Several examples can be found here Bonus: Mocking and Testing When building out authorization schemes, it can tricky to mock the scenarios and test out different flows for multiple users or groups to see how the authorization rules will actually run in production. You should look to implement mocking and simulation techniques for authorization with any system which will return data to clients. AWS AppSync provides a few different for this. First, AppSync that allows you to mock the GraphQL request & response context. You can use this to see what the behavior will be with different scenarios and information passed or received in resolvers. For instance if I edit the resolver from the AppSync console, and select the button I can create a mock context object simulating the user as well as any response. Using the Lambda resolver from earlier I’ll pass in the result to simulate an unauthorized request: tools supports a full test and debug flow getData Select test context AUTHORIZATION_ERROR Pressing the button in the console will evaluate the request object, including field and identity information, as well as perform any conditional checks. If the logic results in an unauthorized request that will be printed to the screen: Test After mocking your data, you can also run this “live” from the page of the AppSync console which can . But don’t stop there, the console also allows you to login with a valid user account from Amazon Cognito User Pools to perform a real authorization check: Queries live stream results from Amazon CloudWatch Logs You can use this to test conditional rules against user accounts, groups, claims or other properties of the identity context object. Summary These are just a few examples of using GraphQL along with the use cases and techniques. Security controls can be a complex subject in general, so it’s always best to take a look at all of the options and when possible, start simple and only add more when your business requirements change. existing AWS AppSync authorization Richard Threlkeld ( @undef_obj ) works at AWS Mobile and was part of the teams that launched AWS AppSync and AWS Amplify , All opinions expressed herein are my own.

AUTO-OWNERS INSURANCE

auto-owners.com

1K-5K employees

Since 1916

COMPANY RANKING

AUTO-OWNERS INSURANCE

EVERGREEN INDEX #1234

Representing this company? Click here to claim and customize this page!

Auto-Owners Insurance WIKI

Apply to get your Tech Company News Page live on HackerNoon.com today!

AUTO-OWNERS INSURANCE

auto-owners.com

1K-5K employees

Since 1916

COMPANY RANKING

AUTO-OWNERS INSURANCE

EVERGREEN INDEX #1234

RELATED COMPANIESRANK

STORIES ABOUT AUTO-OWNERS INSURANCE

Representing this company? Click here to claim and customize this page!

Auto-Owners Insurance WIKI

Apply to get your Tech Company News Page live on HackerNoon.com today!