5 Reasons you should go with PWAs for your Web and Mobile Apps

16 ways to add More Hours to the Day

A twenty five hour day isn’t coming any time soon with Covid19. Twenty four is all that we get. However, with a bit of skill you can squeeze out a couple more hours to add to your day from personal and work time. Here’s how to have more :

Work in blocks.
Learn how to say no.
Cut down on TV/Netflix.
Plan you week in advance.
Limit your social media time.
Don’t be busy just to be busy.
Don’t do everything…delegate.
Unsubscribe from useless e-mails. Do some Triage:

Take a 10-minute break after 1 hour of work.

Prioritize work and schedule online facetime with friends and family, due to covid lockdown. 

Only watch 1 hour of TV/Netflix at night to wind down once work is complete.

Make a list of what has to be done for the week and on what days. 

Don’t make excuses and find things to clean to procrastinate. 

09. Exercise - Plan workouts during your work breaks (10 min chunks) so you can get the most exercising done throughout the day.

10. Do most important tasks in AM.

11. Be good at planning and organizing. 

12. Disable notification for useless apps.

13. Find tasks to eliminate or automate.

14. One task at a time (no multitasking).

15. Always set reminders on your phone.

16.Write stuff down so you don’t forget.

Don’t waste time re-writing texts. 

AM is best for maximizing productivity.

Use accurate time frames for task – make sure to have extra time in case a task takes longer than expected. They are distracting. 

Use alarm app. 

Make use of agenda and post-its.

The final question isn’t just of doing things faster, but of doing the right things. Constantly measure and be aware of the actual value each of your personal and work activities brings. Those that don’t add much should be simplified or eliminated entirely to focus on those that work.

7 Steps in implementing a Zero Trust Architecture

In the past, cyber defences used to focus on a ‘perimeter’ consisting of geographical proximity. Therefore, everything within the security perimeter was confined to the office building. Today, fewer employees are required to go to an office to work since they can access an organization’s assets through mobile devices and cloud software, regardless of where they are located. Unfortunately, this gives cyber criminals more entry points to collect and damage an organization’s assets. 

ZTA, developed by Forrester’s John Kindervag in 2010, is one of the best ways to secure any kind of cyber assets for most organizations. The basic principles of zero trust are:

-        Assume network is always hostile.
-        Assume internal/external threats are always present.
-        Assume internal network is not sufficient to equal trusted.

As not all organizations looking to implement ZTA are doing so under the same circumstances, let’s look at the two different varieties of implementation:

Pure ZTA creation – This is also known as a ‘greenfield’ approach. New companies without cybersecurity architecture or those seeking a makeover of their existing systems are effectively starting over from scratch. 
Hybrid ZTA and perimeter system – More commonly, companies looking to incorporate ZTA into their cyberdefences will be integrating zero trust concepts into an existing perimeter-focused cybersecurity system.

7 steps to implementing a Zero Trust Architecture 

Step 1: Identifying Actors

The first stem is establishing the actors (who) of your system. This entails knowing who your users are, who potential threats may be, etc. This involves a process of detailed recordkeeping and account management, including:

-        All individual users and their characteristics
-        All nonperson entities (NTE) and their functions
-        All attributes and roles associated with every account

Step 2: Identifying Assets 

The second step is establishing the ‘what’ of your system. This requires you to develop and maintain a catalog of all individual resources of assets that are part of your system. This list includes, but is not limited to:

-        Enterprise owned hardware

Computers and laptops

Mobile devices, tables, etc.

All IoT devices (e.g. Belkin WeMo Smart Light Switch, Amazon Echo Plus Voice Controller, Google Home Voice Controller)

-        Unowned assets that regularly connect to enterprise resources

Employee devices

Client devices

Third-party devices

-        Digital artifacts

All software and applications

User accounts and relevant data (see above)

Certificates and other digital or virtual resources

Step 3: Identifying Processes

Completing the initial inventory means keeping track of all processes in your system. 

Companies may not be able to catalog all the information in Step 2, therefore it is important to set up a system that can efficiently scan a new asset and index it immediately. That way, your database adapts over time as assets are added, removed, or changed.

This requires not only identifying all the processes, but also categorizing and ranking them with respect to stakes and cybersecurity needs. Processes to be gauged in this manner include:

-        Protocols
-        Data flows
-        Work flows
-        Transactions
-        Structured events

Step 4: Formulating Policies 

This step is where you move on to the establishment of rules and practices. It is therefore important to utilize the information gathered over the cataloguing stages to gauge the importance of a given actor, asset, or process to the overall ZTA scheme and the broader cybersecurity of the organization.

It is highly recommended to begin with smaller or lower-stake process or asset. For instance, an application used by a small and defined subset of users is preferable for first adoption than one used by all users.

Once the right process or asset is chosen, policies regarding specific cybersecurity needs and means can be drafted. 

The policies define:

-        Which credentials or authenticating factors are appropriate for access
-        What information is eligible for the algorithm calculating access approval

-        How the algorithm for access is to be calculated:

Logistics of access approval and denial
Priority and relevance of information
Exceptional cases and exceptions

Step 5: Producing Solutions

The fifth step involves creating the solutions by putting into action all the data collection and policy planning. 

Here, you draft a list of viable solutions or deployments of ZTA to be used on one or more candidates identified in Step 4. These solutions are also guided by the policies outlined in Step 4. 

You must determine which solution to implement. Things to consider when choosing from your list of solutions include:

-        Does the solution enable data collection analysis?
-        Does it require installation of components?
-        Does location impact its efficacy?

Once a solution is chosen, you materialize it through deployment. 

Step 6: Beginning Deployment and Monitoring 

The sixth step involves putting your solution in place, deploying it on and through the various components that make up your ZTA architecture for the selected candidate(s). Actual changes are finally implemented to your cyberdefence framework. 

It is highly recommended to have one or more trial runs before deploying the solution in full force. Initial hiccups are likely, such as 

-        The system may be overly cautious, not granting access where it should.

-        The system may be improperly lax, granting more access than it should. 

-        The system may no properly handle special cases.

This step is not complete until the deployment of ZTA components on the chosen candidates is fully deployed. Once complete, you will have successfully implemented ZTA. 

Step 7: Expanding the Framework

This last step requires you to return to the fourth step. Insights from your first run through steps five and six will guide your decisions as you return to Step 4. 

Once you decided that the initial ZTA deployment on chosen candidates is functional and stable, because: 

-        you are monitoring the ZTA and loggin all traffic,
-        changes and adjustments are few and minor, and
-        operation involves little to no maintenance.

At this point, your deployment is successful. Moving forward you need to identify a new round of candidates for ZTA deployment, then designing the plan – until you enable cybersecurity for the complete list of applications that require protection, it should include application, data and infrastructure in your model implementation.

5 Reasons you should go with PWAs for your Web and Mobile Apps

Are you creating an application and you need to decide whether to make it Web or a Native development.

Will be covering Progressive Web Apps (PWAs) and 5 reasons why tyou should select PWAs for your web and mobile apps. 

What are PWAs?

In simple terms, they are applications that are built and live on the web but function like Native Applications. 

Users spend a significant amount of more time on Native Apps than on the mobile Web. Think about it, do you open up a browser to use Google Maps on a mobile?

5 Reasons you should go with PWAs for your Web & Mobile Apps

1. Technology

A survey by Stack Overflow suggests that JavaScript and HTML/CSS are the most commonly used programming language. These results influence the technology adoption by developers, and as a result, it is easier to find developers on the web track.

PWAs reduce development costs and deliver faster. Using the same stack for Native and Web is a way to reuse code as much as possible. By sharing and managing your reusable components/modules in cloud component hubs, you are able to focus on composing apps instead of building from scratch for multiple technologies and platforms.

2. Reliable Performance

PWAs are fast, integrated, reliable, and engaging.  

èFast: Users expect PWAs to load quickly. It is worth noting that users are more likely to abandon a site, and less likely to visit a site, with longer load time.

èIntegrated: Users should be able to interact with PWAs the same way they interact with Apps. This includes having all the capabilities and hardware access that other Apps have, such as ApplePay or AndroidPay. 

èReliable: Users do not expect the Web to work when offline, whereas App users expect Apps to work offline. PWAs are connectivity-independent and should work in areas of low connectivity or offline. 

èEngaging: Using features like Web Push to keep the App up-to-date and push notifications to keep users engaged. 

3. Provides Best User Experience using Service Workers

Service Workers are often used in new web apps and can also be used in PWAs. Let us look at the main features Service Workers offers for PWAs.

Working Offline: With Service Workers, you can cache the application shell, and it will load instantly when the user visits back. These background operations allow improving the user experience of the application since the user won’t see any significant differences between online and offline modes. But the dynamic content will only be refreshed when there is a connection.
Background Sync: With Service Workers, the application is able to respond to critical requests once the connection is available. For example, if you send a message when you are offline, service worker will take care of that and complete that request when the connection is available.

4. Native App Look and Feel

Web Apps are easy to use, do not require installation, and they are multi-platform. On the other hand, Native Apps are easier to access on a device, load quickly, and have more hardware capabilities. 

With Progressive Web Apps, you can get the best of both worlds. This is because PWAs have features such as push notifications and background syncing and are installable on a mobile devices.

5. Enhance Security and Transparent Access to Device Capabilities

PWA enforces transport layer security. Therefore, users' information will be encrypted during transmission, and data can only be decrypted using a private key stored on the server. For this reason, PWA website follow best security practices using HTTPS, and the installation of an SSL certificate in the server is done.

Moreover, PWA does not interact with the device hardware without users’ permission. So, by requesting only necessary access to a user's device and using trusted JavaScript libraries which are kept up to date, the risk of malicious codes inside PWA becomes significantly lower.

appsconsultant.com

appsconsultant.com

About us

Latest news

16 ways to add More Hours to the Day

7 Steps in implementing a Zero Trust Architecture

5 Reasons you should go with PWAs for your Web and Mobile Apps

What we offer

Business & Technology Consulting