F5 and Promon Have Partnered to Protect Native Mobile Applications from Automated Bots - Easily
This DevCentral article provides details on how F5 Bot Defense is used today to protect against mobile app automated bot traffic from wreaking havoc with origin server infrastructure and producing excessive nuisance load volumes, and in turn how the Promon Mobile SDK Integrator is leveraged to speed the solution's deployment. The integrator tool contributes to the solution by allowing the F5 anti-bot solution to be inserted into customer native mobile apps, for both Apple and Android devices, with a simple and quick “No Code” approach that can be completed in a couple of minutes. No source code of the native mobile app need be touched, only the final compiled binaries are required to add the anti bot security provisions as a quick, final step when publishing apps. Retrieving Rich, Actionable Telemetry in a Browser World In the realm of Internet browser traffic, whether the source be Chrome, Edge, Safari or any other standards-based web browser, the key to populating the F5 anti-bot analytics platform with actionable data is providing browsers clear instructions of when, specifically, to add telemetry to transactions as well as what telemetry is required. This leads to the determination, in real time, of whether this is truly human activity or instead automated, negative hostile traffic. The “when” normally revolves around the high value server-side endpoint URLs, things like “login” pages, “create account” links, “reset password” or “forgot username” pages, all acting like honeypot pages where attackers will gravitate to and direct brute force bot-based attacks to penetrate deep into the service. All the while, each bot will be cloaked to the best of their abilities as a seemingly legitimate human user. Other high-value transaction endpoints would likely be URLs corresponding to adding items to a virtual shopping cart and checkout pages for commercial sites. Telemetry, the “what” in the above discussion, is to be provided for F5 analytics and can range from dozens to over one hundred elements. One point of concern is inconsistencies in the User Agent field produced in the HTTP traffic, where a bot may indicate a Windows 10 machine using Chrome via the User Agent header, but various elements of telemetry retrieved indicate a Linux client using Firefox. This is eyebrow raising, if the purported user is misleading the web site with regards to the User Agent, what is the traffic creator’s endgame? Beyond analysis of configuration inconsistencies, behavioral items are noted such as unrealistic mouse motions at improbable speeds and uncanny precision suggesting automation, or perhaps the frequent use of paste functions to fill in form fields such as username, where values are more likely to be typed or be auto filled by browser cache features. Consider something as simple as the speed of key depressed and the key being released upward, if signals indicate an input typing pace that defies the physics of a keyboard, just milliseconds for a keystroke, this is another strong warning sign of automation. Telemetry in the Browser World Telemetry can be thought of as dozens and dozens of intelligence signals building a picture of the legitimacy of the traffic source. The F5 Bot Defense request for telemetry and subsequently provided values are fully obfuscated from bad actors and thus impossible to manipulate in any way. The data points lead to a real time determination of the key aspect of this user: is this really a human or is this automation? This set of instructions, directing browsers with regards to what transactions to decorate with requested signals, is achieved by forcing browsers to execute specific JavaScript inserted into the pages that browsers load when interacting with application servers. The JavaScript is easily introduced by adding JavaScript tags into HTML pages, specifically key returned transactions with “Content Type=text/HTML” that subsequently lead to high value user-side actions like submission of user credentials (login forms). The addition of the JavaScript tags is frequently inserted in-line to returned traffic through a F5 BIG-IP application delivery controller, the F5 Shape proxy itself, or a third-party tag manager, such as Google Tag Manager. The net result is a browser will act upon JavaScript tags to immediately download the F5 JavaScript itself. The script will result in browsers providing the prescribed rich and detailed set of telemetry included in those important HTTP transactions that involve high value website pages conducting sensitive actions, such as password resetting through form submissions. Pivoting to Identify Automation in the Surging Mobile Application Space With native mobile apps, a key aspect to note is the client is not utilizing a browser but rather what one can think of a “thick” app, to borrow a term from the computer world. Without a browser in play, it is no longer possible to simply rely upon actionable JavaScript tags that could otherwise be inserted in flight, from servers towards clients, through application delivery controllers or tag managers. Rather, with mobile apps, one must adjust the app itself, prior to posting to an app store or download site, to offer instructions on where to retrieve a dynamic configuration file, analogous to the instructions provided by JavaScript tag insertion in the world of browsers. The retrieved configuration instruction file will guide the mobile app in terms of which transactions will require “decorating” with telemetry, and of course what telemetry is needed. The telemetry will often vary from one platform such as Android to a differing platform such as Apple iOS. Should more endpoints within the server-side application need decorating, meaning target URLs, one simply adjusts the network hosted configuration instruction file. This adjustment in operations of a vendor’s native mobile application behavior is achieved through F5 Bot Defense Mobile SDK (Software Development Kit) and representative provided telemetry signals might include items like device battery life remaining, device screen brightness and resolution and indicators of device setup, such as a rooted device or an emulator posing as a device. Incorrectly emulated devices, such as one displaying mutually exclusive iOS and Android telemetry, concurrently, allows F5 to isolate troublesome, unwanted automated traffic from the human traffic required for ecommerce to succeed efficiently and unfettered. The following four-step diagram depicts the process of a mobile app being protected by F5 bot defense, from step one with the retrieval of instructions that include what transactions to decorate with telemetry data, through to step four where the host application (the mobile app) is made aware if the transaction was mitigated (blocked or flagged) by means of headers introduced by the F5 Antibot solution. The net result of equipping mobile apps with the F5 Bot Defense Mobile SDK, whether iOS or Android, is the ability to automatically act upon automated bot traffic observed, without a heavy administrative burden. A step which is noteworthy and unique to the F5 mobile solution is the final, fourth step, whereby a feedback mechanism is implemented in the form of the Parse Response header value. This notifies the mobile app that the transaction was mitigated (blocked) en route. One possible reason this can happen is the app was using a dated configuration file, and a sensitive endpoint URL had been recently adjusted to require telemetry. The result of the response in step 4 is the latest version of the config file, with up-to-date telemetry requirements, will automatically be re-read by the mobile app and the transaction can now take place successfully with proper decorated telemetry included. Promon SDK Integrator and F5 Bot Defense: Effortlessly Secure Your Mobile Apps Today One approach to infusing a native mobile app with the F5 Bot Defense SDK would be a programmatic strategy, whereby the source code of the mobile app would require modifications to incorporate the F5 additional code. Although possible, this may not be aligned with the skillsets of all technical resources requiring frequent application builds, for instance for quality assurance (QA) testing. Another issue might be a preference to only have obfuscated code at the point in the publishing workflow where the security offering of the SDK is introduced. In simple terms, the core mandate of native mobile app developers is the intellectual property contained within that app, adding valuable security features to combat automation is more congruent with a final checkmark obtained by protecting the completed application binary with a comprehensive protective layer of security. To simplify and speed up the time for ingestion of the SDK, F5 has partnered with Promon, of Oslo, Norway to make use of an integrator application from Promon which can achieve a “No Code” integration in just a few commands. The integrator, technically a .jar executable known as the Shielder tool at the file level, is utilized as per the following logic. The workflow to create the enhanced mobile app, using the Promon integration tool, with the resultant modified mobile app containing the F5 (Shape) SDK functions within it, consists of only two steps. 1. Create a Promon SDK Integrator configuration file 2. Perform the SDK injection An iOS example would take the follow form: Step 1: python3 create_config.py --target-os iOS --apiguard-config ./base_ios_config.json --url-filter *.domain.com --enable-logs --outfile sdk_integrator_ios_plugin_config.dat Step 2: java -jar Shielder.jar --plugin F5ShapeSDK-iOS-Shielder-plugin-1.0.4.dat --plugin sdk_integrator_ios_plugin_config.dat ./input_app.ipa --out . /output_app.ipa --no-sign Similarly, an Android example would remain also a simple two-step process looking much like this: Step 1: python3 create_config.py --target-os Android --apiguard-config ./base_android_config.json --url-filter *.domain.com --enable-logs --outfile sdk_integrator_android_plugin_config.dat Step 2: java -jar Shielder.jar --plugin F5ShapeSDK-Android-Shielder-plugin-1.0.3.dat --plugin sdk_integrator_android_plugin_config.dat ./input_app.apk --output ./output_app.apk In each respective “Step 1”, the following comments can be made about the create_config.py arguments: target-os specifies the platform (Apple or Android). apiguard-config will provide a base configuration .json file, which will server to provide an initial list of protected endpoints (corresponding to key mobile app exposed points such as “create account” or “reset password”), along with default telemetry required per endpoint. Once running, the mobile app equipped with the mobile SDK will immediately refresh itself with a current hosted config file. url-filter is a simple means of directing the SDK functions to only operate with specific domain name space (eg *.sampledomain.com). Url filtering is also available within the perpetually refreshed .json config file itself. enable-logs allows for debugging logs to be optionally turned on. outfile specifies for file naming of the resultant configuration.dat file, which is ingested in step 2, where the updated iOS or Android binary, with F5 anti-bot protections, will be created. For Step 2, where the updated binaries are created, for either Apple iOS or Android platforms, these notes regard each argument called upon by the java command: shielder.jar is the portion of the solution from Promon which will adjust the original mobile application binary to include F5 anti-bot mobile security, all without opening the application code. F5ShapeSDK-[Android or iOS]-Shielder-plugin-1.0.3.dat is the F5 antibot mobile SDK, provide in a format consumable by the Promon shielder. The remaining three arguments are simply the configuration output file of step 1, the original native mobile app binary and finally the new native mobile app binary which will now have anti-bot functions. The only additional step that is optionally run would be re-signing the new version of the mobile application, as the hash value will change with the addition of the security additions to the new output file. Contrasting the Promon SDK Integrator with Manual Integration and Mobile Application Requirements The advantage of the Promon Integrator approach is the speed of integration and the lack of any coding requirements to adjust the native mobile application. The manual approach to integrating F5 Bot Defense Mobile SDK is documented by F5 with separate detailed guides available for Android and for iOS. A representative summary of the steps involved include the following check points along the path to successful manual SDK integration: o Importing the provided APIGuard library into Android Studio (Android) and Xcode (iOS) environments o The steps for iOS will differ depending on whether the original mobile app is using a dynamic or static framework, commands for both Swift and Objective-c are provided in the documentation o The F5 SDK code is already obfuscated and compressed; care should be followed not to include this portion of the revised application in existing obfuscation procedures o Within Android Studio, expand and adjust as per the documentation the Gradle scripts o Initialize the Mobile SDK; specific to Android and the Application Class the detailed functions utilized are available with the documentation, including finished initialization examples in Java and Kotlin o Specific to iOS, initialize the mobile SDK in AppDelegate, this includes adding APIGuardDelegate to the AppDelegate class as an additional protocol, full examples are provided for Swift and Obective-c o Both Android and iOS will require a GetHeaders functions be invoked through code additions for all traffic potentially to be decorated with telemetry, in accordance with the instructions of the base and downloaded configuration files As demonstrated the by the list length of these high-level and manual steps above, which involve touching application code, the alternative ease and simplicity of the Promon Integrator two command offering may be significant in many cases. The platform requirements for the F5 Bot Defense and Promon paired solution are not arduous and frequently reflect libraries used in many native mobile applications developed today. These supported libraries include: o Android: HttpURLConnection, OkHttp, Retrofit o iOS: NSURLSession, URLSession, Alamofire Finally, mobile applications that utilize WebViews, which is to say applications using browser-type technologies to implement the app, such as support for Cascading Style Sheets or JavaScript, are not applicable to the F5 Bot Defense SDK approach. In some cases, entirely WebView implemented applications may be candidates for support through the browser style JavaScript-oriented F5 Bot Defense telemetry gathering. Summary With the simplicity of the F5 and Promon workflow, this streamlined approach to integrating the anti-bot technology into a mobile app ecosystem allows for rapid, iterative usage. In development environments following modern CI/CD (continuous integration/continuous deployment) paradigms, with build servers creating frequently updated variants of native mobile apps, one could invoke the two steps of the Promon SDK integrator daily, there are no volume-based consumption constraints.N6/S/Gi-LAN Mobile network services consolidation in 5G networks
Multiple point products in N6/S/Gi-LAN networks increase costs, complexity, and deployment times. The F5 solution provides a simpler resolution to complexity issues that can dramatically improve efficiency, scale network services more cost-effectively, and enhance network performance. Check out my Lightboard Lessons video.
AppSec Made Easy: Anti-Bot for Mobile APIs
Learn how to use the F5 Advanced Web Application Firewall to easily lock down your applications so that bots can’t attack your mobile APIs. Integrating an SDK can be challenging, but this video will show you the quick way to add anti-bot and other protections directly into your mobile app. See the entire AppSec Made Easy series.Bait Phone
You may be familiar with the truTV program Bait Car, where the police place a vehicle equipped with hidden cameras and radio trackers in various areas to catch a would be car thief in the act. It’s kinda fun to watch people ‘check out’ the car, check out the surroundings and decide to jump in and drive off. You get to see their excitement as they think that they’ve just won the jackpot along with the utter despair as officers remotely kill the car and the thief is surrounded. Even the excuses as to why they are driving it are hilarious. ‘I was just moving it for my friend, so they wouldn’t get a ticket, whose name I forgot and I also can’t remember where they live.’ In the UK, they got something similar except with mobile phones called ‘Operation Mobli.’ Plain clothes police purposely left "bait" phones embedded with tracking devices in nine pubs and bars across the towns of Hastings and St Leonards in Sussex. I’m not sure what makes and models of phones were left for the taking but none of the baited devices were stolen. In every case, an honest patron noticed the ‘forgotten’ phone and turned in to the bar staff. Some might describe this sting as a failure but according to the Sussex Police’s press release Sgt Ché Donald said, ‘This was an excellent result and my faith has been restored as the phones were honestly handed in.’ I often write about the potential perils of losing a smartphone crammed with private data and all the unfortunate circumstances that follow. If it gets into the wrong hands then that is the case yet we must also remember that there are plenty of good, honest folks out there who will do the right thing when they find something that doesn’t belong to them. Maybe they’ve seen police sting shows, maybe they’ve lost something themselves, maybe their parents raised them right or maybe it’s simply kindness and honesty that’s built into every one of us. Human’s are capable of the greatest good and the nastiest of evil, it’s all how we decide to play it. ps References: Operation Mobli deters mobile phone thieves in Hastings Police mobile phone sting fails when.. err.. no handsets stolen Mobile-phone 'sting' reveals honesty of Sussex pubgoers Police Sting Operation Yields No Mobile Phone Thefts It's legal: cops seize cell phone, impersonate owner What’s in Your Smartphone? Freedom vs. Control BYOD–The Hottest Trend or Just the Hottest Term Will BYOL Cripple BYOD?
What Does Mobile Mean, Anyway?
We tend to assume characteristics upon hearing the term #mobile. We probably shouldn’t… There are – according to about a bazillion studies - 4 billion mobile devices in use around the globe. It is interesting to note that nearly everyone who notes this statistic and then attempts to break it down into useful data (usually for marketing) that they almost always do so based on OS or device type – but never, ever, ever based on connectivity. Consider the breakdown offered by W3C for October 2011. Device type is the chosen taxonomy, with operating system being the alternative view. Unfortunately, aside from providing useful trending on device type for application developers and organizations, this data does not provide the full range of information necessary to actually make these devices, well, useful. Consider that my Blackberry can either connect to the Internet via 3G or WiFi. When using WiFi my user experience is infinitely better than via 3G and, if one believes the hype, will be even better once 4G is fully deployed. Also not accounted for is the ability to pair my Blackberry Playbook to my Blackberry phone and connect to the Internet via that (admittedly convoluted) chain of connectivity. Bluetooth to 3G or WiFi (which in my house has an additional chain on the LAN and then back out through a fairly unimpressive so-called broadband connection). But I could also be using the Playbook’s built-in WiFi (after trying both this is the preferred method, but in a pinch…) You also have to wonder how long it will be before “mobile” is the GPS in your car, integrated with services via Google Map or Bing to “find nearby” while you’re driving? Or, for some of us an even better option, find the nearest restroom off this highway because the four-year old has to use it – NOW. Trying to squash “mobile” into a little box is about as useful as trying to squash “cloud” into a bigger box. It doesn’t work. The variations in actual implementation in communication channels across everything that is “mobile” require different approaches to mitigating operational risk, just as you approach SaaS differently than IaaS differently than PaaS. Defining “mobile” by its device characteristics is only helpful when you’re designing applications or access management policies. In order to address real user-experience issues you have to know more about the type of connection over which the user is connecting – and more. CONTEXT is the NEW BLACK in MOBILE This is not to say that device type is not important. It is, and luckily device type (as well as browser and often operating system), are an integral part of the formula we all “context.” Context is the combined set of variables that make it possible to interpret any given connection with respect to its unique client, server, network, and application needs. It’s what allows organizations to localize, to hyperlocalize, and to provide content based on location. It’s what enables the ability to ensure performance whether over 3G, 4G, LAN, or congested WAN connections. It’s the agility to route application requests to the best server-side location based on a combination of client location, connection type, and current capacity across multiple sites – whether cloud, managed hosting, or secondary data centers. Context is the ‘secret sauce’ to successful application delivery. It’s the ingredient that makes it possible to make the right decisions at the right time based on current conditions that address operational risk – performance, security, and availability. Context is what makes the application delivery tier of the modern data center able to adapt dynamically. It’s the shared data that forms the foundation for the collaboration between application delivery network infrastructure and provisioning systems both local and in the cloud, enabling on-demand scalability and at some point, instant mobility in an inter-cloud architecture. Context is a key component to an agile data center, because it is only be inspecting all the variables that you can interpret them in a way that leads to optimal decisions with respect to the delivery of an application, which includes choosing the right application instance whether it’s deployed remotely in a cloud computing environment or locally on an old-fashioned piece of hardware. Knowing what device a given request is coming from is not enough, especially when the connection type and conditions cannot be assumed. The same user on the same device may connect via two completely different networking methods within the same day – or even same hour. It is the network connection which becomes a critical decision point around which to apply proper security and performance-related policies, as different networks vary in their conditions. So while we all like to believe that our love of our chosen mobile platform is vindicated by statistics, we need to dig deeper when we talk about mobile strategies within the walls of IT. The device type is only one small piece of a much larger puzzle called context. “Mobile” is as much about the means of connectivity as it is the actual physical characteristic of a small untethered device. We need to recognize that, and incorporate it into our mobile delivery strategies sooner rather than later. [Updated: This post was updated 2/17/2012 - the graphic was updated to reflect the proper source of the statistics, w3schools ] Long-distance live migration moves within reach HTML5 Web Sockets Changes the Scalability Game At the Intersection of Cloud and Control… F5 Friday: The Mobile Road is Uphill. Both Ways More Users, More Access, More Clients, Less Control Cloud Needs Context-Aware Provisioning Call Me Crazy but Application-Awareness Should Be About the Application The IP Address – Identity Disconnect The Context-Aware CloudWhat to Expect in 2017: Mobile Device Security
We are mobile, our devices are mobile, the networks we connect to are mobile and the applications we access are mobile. Mobility, in all its iterations, is a huge enabler and concern for enterprises and it'll only get worse as we start wearing our connected clothing to the office. If the last 10 years wasn’t warning enough, 2017 will be a huge year for mobile…again. Every year, it seems, new security opportunities, challenges and questions surround the mobile landscape. And now it encompasses more than just the device that causes phantom vibration syndrome, it now involves the dizzying array of sensors, devices and automatons in our households, offices and municipalities. Mobile has infiltrated our society and our bodies along with it. So the security stakes are high. The more we become one with our mobile devices, the more they become targets. It holds our most precious secrets which can be very valuable. We need to use care when operating such a device since, in many ways, our lives depend on it. And with the increased automation, digitization and data gathering, there are always security concerns. So how do we stay safe? The consumerization of IT technologies has made us all administrators of our personal infrastructure of connected devices. Our digital self has become a life of its own. As individuals we need to stay vigilant about clicking suspicious links, updating software, changing passwords, backing up data, watching financial accounts, having AV/FW and generally locking down devices like we do the doors to our home. Even then, the smartphone enabled deadbolt can be a risk. And we haven’t even touched on mobile payment systems, IoT botnets or the untested, insecure apps on the mobile phone itself. Cybersecurity is a social issue that impacts us all and we all need to be accountable. For enterprises, mobile devices carry an increased risk, especially personal devices connecting to an internal network. From regulatory compliance to the disgruntled employee, keeping sensitive information secret is top concern. BYOD policies and MDM solutions help as does segmenting those devices away from critical info. And the issue isn’t so much seeing restricted information, especially if your job requires it, it is more about unauthorized access if the device is compromised or lost. Many organizations have policies in place to combat this, including a total device wipe…which may also blast your personal keepsakes. The endpoint security market is maturing but won’t fill the ever-present security gaps. From your workforce to your customers, your mobile web applications are also a target. The Anti-Phishing Working Group (APWG) reports a 250 percent jump in the number of detected phishing websites between October 2015 and March 2016. Around 230,000 unique phishing campaigns a month, many aimed at mobile devices arriving as worrisome text messages. Late 2016 saw mobile browsing overtake desktop for the first time and Google now favors mobile-friendly websites for its mobile search results. A double compatibility and SEO whammy. And those two might not be the biggest risk to an organization since weakest link in the security ecosystem might be third-party vendors and suppliers. On the industrial side, tractors, weather sensors, street lights, HVAC systems, your car and other critical infrastructure are now mobile devices with their own unique security implications. The Industrial Internet of Things (IIoT) focuses on industrial control systems, device to network access and all the other connective sensor capabilities. These attacks are less frequent, at least today, but the consequences can be huge – taking out industrial plants, buildings, farms, and even entire cities. The Digital Dress Code has emerged and with 5G on the way, mobile device security takes on a whole new meaning. ps Related: Mobile Trends For 2017 And Beyond Perspectives on Securing Mobile and Social Business, 12 Months On RSAC17: More ransomware and IoT-enabled attacks on the way, warns expert Mobile Malware Milestone Mobile banking and how to stay secure What Does Mobile Mean, Anyway? BYOD - concentrate on the apps, not the devices 10 Security Trends To Watch For At RSA 2017You Never Know When...
An old article gets new life. #TBT Back in 2012 I wrote an article titled Bait Phone. It was about cops dropping mobile phones with a tracking device and following the stealing culprit for an arrest. Like Bait Car but with a smartphone. Over the weekend, I noticed that the article was blowing up but couldn’t figure out why: I even tweeted out on Monday: At the time, I didn't realize something else was at play. Then I decided to do a twitter search: And found that a video with the same name as my blog post was trending: Bait Phone 2 - basically a stun gun with a remote. Over 2.2 million YouTube views in less than a week. It’s a prank video where they have a remote zapper to sting the culprits when they grab & walk away with the phone. One guy - who had it in his pocket - denied taking it until he was personally shocked. When I did a Google search over the weekend, my article was still at the top but now the article is like #13 listed (maybe even lower) and the video has taken the top spot. You never know when an old article might pop due to some other circumstances. At least folks are reading it and not totally bailing! Fun stuff. psMeet the Sensors
I often write about the Internet of Things, or the soon-to-be-cliché IoT. You know, the smart-fridges, smart-cars, smart-thermostats, healthcare devices, wearables and any of those connected devices that have a sensor, gathers data and reports back to some entity. You are able to control these devices (and see the data) with mobile apps or even your own voice and gestures. They are all the rage and sitting at the top of the Gartner Hype Cycle. But it’s all the various sensors inside those devices that are doing the actual measuring, calculating, tracking and reporting. Each has its own specialty providing specific functionality. I’ve always wondered about what’s inside some of the wearables let’s take a look at a few. Have you ever wondered what spins the screen so you’re not looking at an upside down picture? That’s an Accelerometer. It measures orientation and movement. The iPhone was the first to use this back in 2007 and amazement ensued. It can tell the difference between running away from a charging buffalo in Yellowstone verses making faces with a chimp at the zoo. It can also tell if you’re sleeping simply by the fact that you haven’t moved for a while. These are typically used to track step count and how well you’ve rested. I noted that the accelerometer measures step count but what about those steps up a flight of stairs? Well, that would be the Altimeter. Altimeters measure altitude so it can sense changes in height. In conjunction with the steps the accelerometer counted, the altimeter will add its bits and give you a more accurate calorie count for those fire escape runs. Instead of asking how tall someone is, next time ask ‘What’s your alti?’ And if you’re going to step out for a run, you might want to know if it’ll be sunny or sprinkles during the trek. Often seen as a smaller dial on an outdoor clock but now on wristbands, a Barometer measures atmospheric pressure – the weight of air in the Earth’s atmosphere. It’s used in forecasting the weather and you often hear meteorologists note, ‘There’s a high ridge of atmospheric pressure keeping the rain away.’ At least that’s what they’ve been saying in California about the drought. So you thought of attempting an Iron Man competition but wondered if your device could differentiate between the swimming, biking and running. You’re in luck if your device has a Gyroscope. Using the Earth’s gravity, it can help determine orientation. The big difference between an accelerometer and a gyroscope is that a gyroscope can also measure rotation or more specifically, the rate of rotation around a particular axis. Gyroscopes take into account the Earth’s gravity and rotation while the accelerometer does not. If tracking stars for navigation and location like the early Polynesians is not your style, then the ever popular GPS is your tool. Using three satellites to ‘triangulate’ your location, the receiver measures distance to the first satellite. Based on that, you are in a certain sphere location on the planet. It then measures the distance to the second satellite to get another sphere location. Therefore, you must be somewhere on the circle where these two spheres intersect. By using a third satellite reading, the sphere that cuts through the circle of the intersection of the first two spheres narrows your location even more. Now our position is narrowed to two points in space. One of those two points is so absurd and instantly tossed, thus leaving you with an exact location. There are a bunch of other sensors like Optical Heart Rate Monitors, typically worn on the wrist and it shines a tiny light against your skin to measure the blood pumping through your arm veins. And the various Gesture Tech things that use a little camera to see your hand and body movements to translate that into action on a gaming device, or a drone following your Snake River Canyon jump or even turning up the volume on the TV. It’d be cool to move something out of the way by effortlessly swiping your hand in the air, huh? Sensors have been all around us for a while but now they are becoming close confidants. We should get to know our new Ohana. ps Related What do the sensors in wearable tech actually do? The World's First Urine-Powered Wearable Is Here Accelerometer vs. Gyroscope: What's the Difference? Wearables Head to Tail Oh, Is That The Internet You're Wearing? Connecting the Threads Our Five Senses on Sensors Sensors and IoT Technorati Tags: iot,wearables,sensors,humans,silva,f5,mobile Connect with Peter: Connect with F5:Blog Roll 2015
It’s that time of year when we gift and re-gift, just like this text from last year. And the perfect opportunity to re-post, re-purpose and re-use all my 2015 blog entries. If you missed any of the 89 attempts including 59 videos, here they are wrapped in one simple entry. I read somewhere that lists in blogs are good. I broke it out by month to see what was happening at the time and let's be honest, pure self-promotion. Thanks for reading and watching throughout 2015. Have a Safe and Happy New Year. January 2015 OK 2015, Now What? The Analog Generation Application Availability Between Hybrid Data Centers Will Deflate-Gate Lead to Micro-Chipped Footballs? VMware Partner Exchange 2015: Video Preview February VMware PEX 2015 – Find F5 VMware PEX 2015 – What Customers Want From Security Vendors VMware PEX 2015 – BIG-IP on vCloud Air VMware PEX 2015 – F5 Channel Partner Ecosystem VMware PEX 2015 – That’s a Wrap! 5 Ways #IamF5 The Internet of Me, Myself & I Intelligent DNS Animated Whiteboard Mobile World Congress 2015 - The Preview Video March MWC 2015 - Find F5 MWC 2015 – NFV for Service Providers (feat Yue) MWC 2015 – Threats to Mobile Carrier Networks (feat George) MWC 2015 – How LTE Roaming Works (feat Nas) MWC 2015 – Getting Work Done on the Go (feat Carovano) MWC 2015 - SDN Demystified (feat Duncan) MWC 2015 – TCP Opt for Service Providers (feat Yue) MWC 2015 – Enhancing Subscriber’s Quality of Experience (feat Mahmoodi) MWC 2015 – The Mobile Revolution with F5 CEO John McAdam MWC 2015 – That’s a Wrap! Lost in Translation...in Italy April Healthcare in the Crosshairs What are These "Things”? IoT Influence on Society RSA 2015 - The Preview Video RSA2015 – Find F5 RSA2015 Partner Spotlight - RSA Risk Based Authentication RSA2015 – Defending the New Perimeter RSA2015 – The InfoSec Landscape with Jeremiah Grossman RSA2015 Partner Spotlight: FireEye Partnership RSA2015 – SSL Everywhere (feat Holmes) RSA2015 – That’s a Wrap! IoT Effect on Applications May IoT Ready Infrastructure F5 Agility EMEA 2015 - The Preview Video F5 EMEA Agility 2015 - Welcome to Edinburgh What Are You Looking Forward To At F5 Agility 2015? F5 Agility 2015 EMEA – ACI with F5 & Cisco F5 Agility 2015 EMEA – King Robert the Bruce F5 Agility 2015 EMEA – Sir William Wallace That’s a Wrap from EMEA F5 Agility 2015 June The IoT Ready Platform I Almost Bit...and Would've Been Bitten July F5 Animated Whiteboards Is 2015 Half Empty or Half Full? F5Agility15 - The Preview Video August Welcome to F5 Agility 2015 Innovate, Expand, Deliver with F5 CEO Manny Rivelo Get F5 Certified at F5 Agility 2015 Software Defined Data Center Made Easy with F5 and VMware F5 DevCentral Solves Your BIG-IP Questions That's a Wrap from #F5Agility15 Our Five Senses on Sensors VMworld2015 – The Preview Video VMworld2015 – Find F5 VMworld2015 – Realize the Virtual Possibilities (feat. de la Motte) September VMworld2015 – Business Mobility Made Easy with F5 and VMware (feat. Venezia) Software Defined Data Center Made Simple (feat. Pindell) - VMworld2015 That’s a Wrap from VMworld2015 F5 + Blue Medora: Gain Control of Your Applications with vRealize Is Your DNS Vulnerable? October AWS re:Invent 2015 – The Preview Video IoT: Tabs to be Read Later Find F5 at AWS re:Invent 2015 AWS re:Invent 2015 - Value of App Services in the Cloud (feat Vrankic) AWS re:Invent 2015 – SSL Everywhere…Including the Cloud (feat Stanley) AWS re:Invent 2015 – Web Application Firewall in the Cloud (feat Haynes) AWS re:Invent 2015 – Programmability in the Cloud (feat Applebaum) AWS re:Invent 2015 – The F5 Ready Program (feat Pickering) That’s a Wrap from AWS re:Invent 2015 The Wave of Change at Tech Events F5 + SimpliVity: Deploy and Simplify Application Deployments Together Wearables Head to Tail F5 + Nutanix: Invisible Infrastructure and SDAS Joining Forces November Ask the Expert – Are WAFs Dead? Ask the Expert – Why SSL Everywhere? Ask the Expert – Why Web Fraud Protection? Ask the Expert – Why Identity and Access Management? Connecting the Threads Identity Theft: Not So Scary Anymore? F5 Blog: Backseat Drivers, Your Wish Has Come True Inside the ALOHA! December Arguing with Things Punchbowl, Pearl Harbor and my Grandparents The Top 10, Top 10 Predictions for 2016 And a couple special holiday themed entries from years past. e-card Malware X marks the Games ps Related Blog Roll 2014 Blog Roll 2013 Blog Roll 2012 Blog Roll 2011 Technorati Tags: f5,big-ip,security,cloud,mobile,video,silva,2015,blogs,iot,things Connect with Peter: Connect with F5:Optimizing IoT and Mobile Communications with TCP Fast Open
There's a lot of focus on the performance of mobile communications given the incredible rate at which mobile is outpacing legacy PC (did you ever think we'd see the day when we called it that?) usage. There's been tons of research on the topic ranging from the business impact (you really can lose millions of dollars per second of delay) to the technical mechanics of how mobile communications is impacted by traditional factors like bandwidth and RTT. Spoiler: RTT is more of a factor than is bandwidth in improving mobile app performance. The reason behind this isn't just because mobile devices are inherently more resource constrained or that mobile networks are oversubscribed or that mobile communications protocols simply aren't as fast as your mega super desktop connection, it's also because mobile apps (native ones) tend toward the use of APIs and short bursts of communication. Grab this, check for an update on that, do this quick interaction and return. These are all relatively small in terms of data transmitted, which means that the overhead from establishing a connection can actually take more time than the actual exchange. The RTT incurred by the three-step handshake slows things down. That same conundrum will be experienced by smart "things" that connect for a quick check-in to grab or submit small chunks of data. The connection will take longer than the data transmission, which seems, well, inefficient, doesn't it? Apparently other folks thought so too, and hence we have in Internet Draft form a proposed TCP mechanism to alleviate the impact of this overhead known as "TCP Fast Open". TCP Fast Open Draft @ IETF This document describes an experimental TCP mechanism TCP Fast Open (TFO). TFO allows data to be carried in the SYN and SYN-ACK packets and consumed by the receiving end during the initial connection handshake, and saves up to one full round trip time (RTT) compared to the standard TCP, which requires a three-way handshake (3WHS) to complete before data can be exchanged. However TFO deviates from the standard TCP semantics since the data in the SYN could be replayed to an application in some rare circumstances. Applications should not use TFO unless they can tolerate this issue detailed in the Applicability section. The standard relies on the existence of a cookie deposited with the client that indicates a readiness and willingness (and perhaps even a demand) to transmit some of the data in the initial SYN and SYN-ACK packets of the TCP handshake. The cookie is generated by the app (or gateway, the endpoint) upon request from the client. There's no special TCP behavior on this request, so it seems likely this would be handled during the "initial setup" of a thing. On subsequent communications in which the TFO cookie is present, the magic happens. The app (or gateway, the endpoint) recognizes the cookie and is able to grab the data and start processing - before the initial handshake is even complete. While the use of 'cookies' is more often associated with HTTP, it is also found within the realm of TCP (SYN cookies are a popular means of attempting to detect and prevent SYN flood attacks). Needless to say, such a mechanism is particularly of interest to service providers as their networks often act as gateways to the Internet for mobile devices. Reducing the time required for short-burst communications ultimately reduces the connections that must be maintained in the mobile network, thus relieving some pressure on the number of proxies - virtual or not - required to support the growing number of devices and things needing access. A word of caution, however. TFO is not designed for nor meant to be used for every application. The draft clearly spells out applicability as being to those applications where initial requests from the client are of a size that they are less than the TCP MSS. This is because otherwise the server still has to wait until after the handshake completes to gather the rest of the data and formulate a response. Thus any performance benefit would be lost. Proceed with careful consideration, therefore, in applying the use of TCP Fast Open but do consider it, particularly if data sets are small, as may be the case with things reporting in or checking for updates.
