Feed aggregator

In the news

iPhone J.D. - Fri, 08/03/2018 - 01:11

The market capitalization or "market cap" of a company is simply the share price multiplied by the number of shares outstanding, and is one method of indicating the public's opinion of the net worth of the company.  Yesterday, Apple became the first company to ever have a market cap of over a trillion dollars.  When the market closed, Apple's market cap was $1.002 trillion.  I thought that this comment from John Gruber of Daring Fireball was interesting:  "That '.002' looks insignificant but represents $2 billion — about what the entire company was worth in 1996."  It was obvious for a while now that this day was coming, so a number of news sites had articles ready to run when the milestone was crossed.  I'll recommend two of them that were particularly good:  an article by Jack Nicas in the New York Times, and an article by Brad Stone of Bloomberg.  There are lots of reasons that Apple achieved this success, but there is no question that the number one reason was the iPhone.  And now, the news of note from this past week:

  • Illinois attorney Warren Freiberg wrote an article for TechnoLawyer recommending apps that are useful for attorneys.  I myself use recommend almost all of the apps identified in that article.  Click here to download the article in PDF format.
  • I went back and forth about whether to link to this article because the premise is so shaky.  In an article for the ABA's GP Solo, legal consultant Seth Rowland asked his son Samuel Rowland, a college student, to try to figure out what mobile apps lawyers might want to use.  The older Rowland explained that he did this because he hasn't practiced law in two decades and his primary focus is PC software, not mobile apps.  Um, okay, but asking a journalism major to pick the best apps for lawyers seems about as valuable as asking me to pick out the best apps for dentists.  The only qualification offered for the younger Rowland was that he is "an avid cell phone user."  Of course, that also accurately describes most of the kids at my son's middle school.  As you might guess, the article fails to mention a ton of useful (and obvious) apps.  But I'm linking to it anyway because it also names some truly good apps, and any time you look at a list of apps there is always the chance that you will come across an app that speaks to you.  So if you dare, click here to read Legal Apps for the Lawyer on the Go.  (And while I disagree with the premise of this article, kudos to Sam for giving it the old college try and finding some of the good apps.)
  • Earlier this week, I reported on Apple's 2018 fiscal third quarter.  In an article for Macworld, Jason Snell offered four interesting takeaways from the results.  And in an article for Six Colors, Snell digs a little deeper into the results.
  • Bradley Chambers of 9to5Mac recommends some of the best iPhone weather apps.
  • Vanity Fair has an interesting excerpt from an upcoming memoir by Lisa Brennan-Jobs, daughter of Steve Jobs, call Small Fry.  They had an awkward relationship, to say the least, and I enjoyed this excerpt.
  • And finally, this short 15-second video advertising the iPad does a good job of showing why I love my almost-completely paperless law practice, which wouldn't be possible without my iPad.  It is called Paperless Paperwork:

Categories: iPhone Web Sites

Adventures in vulnerability reporting

Google Project Zero - Thu, 08/02/2018 - 14:56
Posted by Natalie Silvanovich, Project Zero

At Project Zero, we spend a lot of time reporting security bugs to vendors. Most of the time, this is a fairly straightforward process, but we occasionally encounter challenges getting information about vulnerabilities into the hands of vendors. Since it is important to user security that software vendors fix reported vulnerabilities in a timely matter, and vendors need to actually receive the report for this to happen, we have decided to share some of our experiences. We hope to show that good practices by software vendors can avoid delays in vulnerability reporting.
Effective Vulnerability Reporting ProcessesThere are several aspects of a bug reporting process that make reporting vulnerabilities easier from the bug reporter’s perspective. To start off, it’s important for a bug reporting process to be easy to find and use. We sometimes have difficulty figuring out how to report a vulnerability in a piece of software if the vulnerability reporting process is not documented on the project or vendor’s website, or if outdated material is not removed and instructions for reporting vulnerabilities are inconsistent. This can lead to delays in reporting. Effective vulnerability reporting processes are clearly documented, and the documentation is easy to find.
We also appreciate when the process for reporting a vulnerability is short and straightforward. Occasionally, we report dozens of vulnerabilities in a vendor’s products, and it is helpful when reporting does not require a lot of clicks and reading. Reporting processes that use email or bug trackers are usually the easiest, though webforms can be easy if they are not excessively long. While Project Zero will always report a vulnerability, even if reporting it is very time consuming, this is not necessarily the case for other bug reporters. Long bug reporting processes can cause bug reporters to report bugs more slowly, spend less time working on a piece of software or even give up on reporting a bug. The easier a bug reporting process is, the more likely it is that someone will go through with it.
It’s also important for bug reporting processes to be well-tested. While the majority we encounter are, we’ve occasionally had bug reporting email addresses bounce, webforms reject necessary information (like the reporter’s name) and security issues go unnoticed in bug trackers for months despite following the documented process. Vendors with good processes usually test that their process and any systems it involves works correctly on a regular basis.
Mandatory legal agreements in the reporting process are another problem that we encounter every so often. If a legal agreement contains language about disclosure or any other subject we don’t feel comfortable entering an agreement about on behalf of our company, deciding whether to enter the agreement can require a lengthy discussion, delaying the bug report. While legal agreements are sometimes necessary for rewards programs and code contributions, good vulnerability reporting processes allow bug reporters to report bugs without them.
It is also helpful when vendors confirm that vulnerability reports have been received in a timely manner. Since bug reports can get lost for a number of reasons, including bugs in the reporting interface and human error, it is a good idea to let reporters know that their report has been received, even if it won’t be processed right away. This lets the reporter know that they’ve reported the bug correctly, and don’t need to spend any more time reporting it, and makes it more likely that bug reporters will reach out if a bug report gets lost, as they will be expecting a confirmation.
Finally, even if good practices are followed in creating the bug reporting process, it is still possible that a bug reporting process has problems, so it is very helpful if vendors provide a way to give feedback on the process. It’s very rare for vendors to intentionally make bug reporting difficult, but unexpected problems happen fairly frequently, so it is good to provide a way bug reporters can reach out for help as a last resort if a reporting a bug fails for any reason.
ExamplesOne example of a bug we had difficulty reporting due to a vendor not following the practices described above is CVE-2018-10751.  CVE-2018-10751 is a remote memory corruption vulnerability in OMACP affecting the Samsung S7 Edge. The issue can be triggered by sending a single SMS to the target device, and does not require any user interaction. The payload can be sent from an app on an Android device without root access or any special equipment. It is similar to CVE-2016-7990, which is described in detail here.
Samsung’s Vulnerability Reporting ProcessCVE-2018-10751 is a serious vulnerability, and I wanted to report it immediately. I started off by reading Samsung Mobile’s Security Reporting page. This page has a button to create a bug report.
https://security.samsungmobile.com/securityReporting.smsb Accessed February 22, 2018
Pressing the button led to a sign-up page. I didn’t have a Samsung account, so I tried to sign up. Unfortunately, it led to this page:
https://security.samsungmobile.com/securityReporting.smsb Accessed February 22, 2018
Not speaking Korean, I wasn’t sure what to do here. I eventually went back to the previous page and tried the ‘Sign-in’ button.
This brought me to an English sign-up page, which then brought me to the account creation page. According to this page, I had to read and agree to some terms. Clicking the links led to over twenty separate agreements, most of which had nothing to do with vulnerability reporting.https://account.samsung.com Accessed February 22, 2018
That’s a lot of text to read and review. Let’s just say I skimmed a bit. Once I clicked ‘Agree’, I was taken to a page where I could enter account information. The page required my birthdate and zip code, which I wasn’t thrilled to have to provide to report a vulnerability, but I wanted to get the issue reported, so I entered them. Finally, my account was created! I logged in, hoping to start reporting the bug, only to be greeted with more conditions.
https://account.samsung.com Accessed February 22, 2018
These ones were in Korean, and I couldn’t figure out how to change the language. Eventually, I just selected confirm. Finally, I got to the form where I could report bugs!
https://security.samsungmobile.com/securityReporting.smsb Accessed February 22, 2018
I filled out the vulnerability information, and scrolled down, and there was one more set of terms to agree to:https://security.samsungmobile.com/securityReporting.smsb Accessed February 22, 2018
These terms included:
- You MUST hold off disclosing the vulnerability in reasonable time, and you MUST get Samsung’s  consent or inform Samsung about the date before disclosing the vulnerability.- In some cases, Samsung may request not to disclose the vulnerability at all.
I was not able to submit this form without agreeing to allow Samsung some level of control over disclosure of reported vulnerability. I looked around Samsung’s security page to see if they provided an email address I could report the issue to, but they did not provide one. I was not comfortable reporting this bug through the mechanisms Samsung provides for vulnerability reporting on their website.
Problems with Vulnerability Reporting Processes
I encountered several problems while trying to report the above vulnerability—most of which have been since resolved by Samsung.
To start off, Samsung’s bug reporting process did not seem adequately tested. The many times that Korean text showed up while attempting to report this vulnerability suggests that it was not tested in English. As described above, is important for vendors to test vulnerability reporting processes, including for internationalization issues. The workflow is also excessively long, and requires the reporter to agree to a very large number of agreements, many of which have nothing to do with vulnerability reports. I suspect that the people testing this interface might have already had accounts, and not seen how long the process is for someone who just wants to report a bug.
This isn’t an uncommon problem. The Android security reporting template requires creating a GMail account, which can require clicking through many screens and verification via SMS in some circumstances. As a result of our feedback, the Android Security team has improved the documentation that vulnerability reports can be filed via email (security@android.com), although using the web form is still required to participate in the Android Security rewards program.
Another problem was that in order to report a bug, a reporter had to agree to the terms of the rewards program. This is an issue that Project Zero has been seeing increasingly often. When software vendors start rewards programs, they often remove existing mechanisms for reporting vulnerabilities, leaving bug reporters with no way to report vulnerabilities without entering into agreements.
This also occurred when Tavis Ormandy attempted to report the vulnerability he reluctantly dubbed CloudBleed. Cloudflare’s vulnerability reporting process is tied to its rewards program with HackerOne, and there is no clear way to report a vulnerability without creating a HackerOne account in their Vulnerability Disclosure Policy. The policy even states “We agree with their disclosure philosophy, and if you do too, please submit your vulnerability reports here” without providing an alternative for vulnerability reporters who don’t agree or don’t want to participate in the program for whatever reason. In Project Zero’s case, our disclosure deadline is 90 days meanwhile HackerOne’s deadline is 180 days. This vulnerability was also very urgent as it was actively leaking user data onto the Internet, and we didn’t want to delay reporting the issue while we read through HackerOne’s terms to determine whether they were compatible with our disclosure policy.
We find that vendors generally don’t intend to prevent bug reports from anyone who won’t agree to their disclosure rules, but this was the end result of Samsung and Cloudflare replacing their bug reporting process with a rewards program.
The specific terms of Samsung’s agreement were also fairly vague. In particular, it wasn’t clear what the consequences of breaking the terms would be. For example:
- You MUST hold off disclosing the vulnerability in reasonable time, and you MUST get Samsung’s  consent or inform Samsung about the date before disclosing the vulnerability.
Does this mean that if someone discloses a vulnerability without permission, they are not eligible for a reward? Does it mean that if someone discloses the vulnerability without permission, Samsung can take legal action against them? While requiring that bug reporters not disclose vulnerabilities to receive rewards is a policy with debatable benefit, I would have been much more comfortable agreeing to these terms if they had spelled out that violating them would simply mean I would not receive a reward, as opposed to other legal consequences. Overall, the issues of poorly tested bug reporting interfaces and requiring legal agreements to report vulnerabilities have come up multiple times, and led to delays of Project Zero reporting vulnerabilities. We recommend that vendors test their vulnerability reporting interfaces from the perspective of someone who’s never reported a bug from outside of their corporate network, and make sure to do localized testing. It is also important to allow bug reports without requiring the reporter to enter into excessive legal agreements.
While only accepting vulnerability reports via web forms can reduce the number of invalid reports, which is a major challenge for teams accepting vulnerability reports, they can also be unreliable and prevent vulnerability reporting in situations that were not expected by those designing them, unless they are very well tested. Having an alternate email address that vulnerability reporters can use to report bugs if they encounter problems is a good way to prevent this type of problem.
Reporting the BugI eventually contacted some members of the Knox security team at Samsung that I had worked with on previous bugs and they recommended reporting the issue to mobile.security@samsung.com. This email is not documented on the Samsung website, except for a single blog post from 2015.
The difficulty I encountered reporting this serious vulnerability delayed my report one week. It might have caused a longer delay if I did not have contacts at Samsung who could help.
Samsung started rolling out updates for CVE-2018-10751 (Samsung’s identifier SVE-2018-11463) in their April maintenance release.
Samsung has updated their account creation page so that it always displays English text if the language is set to English. Also, the vulnerability report form can now be submitted without agreeing to the terms for the Samsung’s rewards program, though the user still has to agree to two other agreements. They have also updated their bug reporting page to provide an email address as well as a webform. We appreciate the changes they have made to make reporting vulnerabilities in Samsung products easier for everyone.
ConclusionProject Zero has occasionally had difficulty reporting vulnerabilities, leading to delays in reporting the bug. Usually, these are due to problems in the reporting process that were not intended or expected by the vendor. A difficult vulnerability reporting process can have a negative impact on user security due to delays in vulnerability reports, lost vulnerability reports and even bug reporters choosing not to report a vulnerability. We appreciate when vendors do the following to make their bug reporting processes easier for bug reporters:
  • Vendors should regularly test their vulnerability reporting interfaces in all supported languages
  • Vendors should streamline their vulnerability reporting processing as much as possible, and remove excessive clicks and legal agreements
  • Vendors should regularly solicit feedback on their vulnerability reporting mechanisms from vulnerability reporters and people they think are likely to report vulnerabilities
Categories: Security

MacTrack / iTrack -- go to Disney World to learn more about using your iPhone and iPad in your law practice

iPhone J.D. - Wed, 08/01/2018 - 23:56

One of the best ways to learn more about getting more out of an iPhone or iPad in your law practice is to hear directly from other attorneys with expertise in this area.  This is one of the reasons that I enjoy going to ABA TECHSHOW in Chicago every Spring.  Having said that, the last few TECHSHOW conferences have not focused on mobile technology as much as I would have liked.  For years, I have heard great things about the MacTrack Legal conference.  The conference has traditionally been focused on helping solo and small firm lawyers who use Macs, but this year — the 10th year of the conference — it will be called MacTrack / iTrack Legal, and most of the conference will focus on using iPhones and iPads.  If you are looking to attend a conference to learn more about using your iOS device, I cannot think of a better place to go.

The conference is September 27 to 29, 2018, at Disney's Yacht & Beach Club at Walt Disney World in Orlando, FL.  It is easy to get flights to Orlando from most anywhere, and it may be easier to justify the trip if your family can join you and attend the parks while you are at the conference.  The conference occurs during the Epcot Food & Wine Festival.  Attendees can take advantage of a discounted hotel rate not only during the conference, but also for three days before and after the conference.

While the venue alone makes this conference attractive, the real reasons for you to go are the speakers and the attendees.  In past years, the speaker list has been fantastic, and the folks who are already identified on the conference website this year are fantastic.  Not only do they know a ton about using an iOS device (and a Mac), but they are also friendly folks and great teachers.  Just to mention a few, I'm big fans of Florida attorney Katie Floyd (of MacPowerUsers), legal tech consultant Brett Burney, New Jersey estate planning attorney Victor Medina (who is planning the conference), Canadian attorney Bjorn "Barney" Christianson, and Pennsylvania attorney Evan Kline.  I've seen all of them teach sessions on using iOS devices, and in some cases I've even co-presented with them.  In addition to the speakers, numerous attorneys have told me that they attend this conference again and again because of the great folks who were attending, which makes sense because this is a smaller and more intimate conference — the opposite of a mega-conference like TECHSHOW.

I had hoped to be able to speak at this conference this year given the focus on iOS, but unfortunately my schedule doesn't permit it.  But if your schedule does, I encourage you to give this one a look.  I know that it will be an enjoyable and incredibly informative conference.

Here is a video in which Victor explains what makes this conference so special:

Here is a link to a PDF file with more information on the individual sessions.

Click here for more information on MacTrack / iTrack Legal.

Categories: iPhone Web Sites

IBM Power Systems H922 and H924 Technical Overview and Introduction

IBM Redbooks Site - Wed, 08/01/2018 - 09:30
Redpaper, published: Wed, 1 Aug 2018

This IBM® Redpaper™ publication is a comprehensive guide that covers the IBM Power System H924 (9223-42H), and IBM Power System H922 (9223-22H) servers that support memory-intensive workloads such as SAP HANA, and deliver superior price/performance for mission-critical applications in IBM AIX®, IBM i, and Linux operating systems.

Categories: Technology

Apple 2018 fiscal third quarter -- the iPhone and iPad angle

iPhone J.D. - Tue, 07/31/2018 - 22:48

Yesterday, Apple released the results for its 2018 fiscal third quarter (which ran from April 1, 2018 to June 30, 2018) and held a call with analysts to discuss the results.  This is typically not a big fiscal quarter for Apple; the important quarter for Apple every year is the first fiscal quarter (containing the holiday sales season).  During the fiscal third quarter, most potential Apple customers — which for the most part means iPhone customers — are waiting to see what new products Apple will introduce in the Fall.  Even so, Apple had their best fiscal third quarter ever, with quarterly revenue of $53.3 billion.  Apple CEO Tim Cook attributed the impressive revenues to three factors:  iPhone sales, service revenue such as the App Store and Apple Music, and wearable product sales such as the Apple Watch and AirPods.  If you want to get all of the nitty gritty details, you can download the audio from the announcement conference call from iTunes, or you can read a transcript of the call prepared by Seeking Alpha, or a transcript prepared by Jason Snell of Six Colors.  Apple's official press release is here.  As always, I'm not as interested in the financial details as I am the statements of Apple executives during the call that are of interest to iPhone and iPad users.  Here are the items that stood out to me.


  • During the past quarter, Apple sold 41.3 million iPhones, just slightly more than the 41 million iPhones sold in 2017's third fiscal quarter. The all-time record for iPhone sales in a fiscal Q3 was in 2015, when Apple sold 47.5 million iPhones.
  • While the increase in the number of iPhones sold versus 2017 Q3 was modest, the increase in revenue from iPhone sales was more impressive thanks to sales of the more expensive iPhone X.  iPhone revenue was $24.8 million in 2017 Q3, but it rose to $29.9 million in 2018 Q3, a 20% increase.
  • By my count, Apple has sold 1.421 billion iPhones since they first went on sale in 2007.
  • What kinds of iPhones are people buying?  For the second quarter in a row, the top-of-the-line iPhone X was the best-seller.  The critics who predicted that few folks would want to pay more for a more powerful iPhone were clearly wrong.


  • Apple sold just over 11.5 million iPads in the fiscal third quarter, around 100,000 more iPads than Apple sold a year ago. 
  • I don't know if Apple will ever return to the larger iPad sales numbers that the company saw many years ago, including a high of 19.5 million iPads in 2013 Q2.  Nevertheless this is now the fifth quarter in a row that the average number of iPads sold has increased, if you look at a four quarter average.
  • By my count, Apple has sold over 415 million iPads since they first went on sale in 2010.
  • Apple CFO Luca Maestri said that almost half of iPad purchases in the past quarter were by customers new to iPad.


  • A relatively new area of revenue for Apple is app subscriptions, such as apps that are free to download but for which you pay a monthly or yearly subscription fee to access more advanced features.  Cook said that the App Store now includes almost 30,000 apps which offer subscriptions.
  • Because the App Store turned 10 years old last month, Cook spent some time noting its impressive numbers, and the App Store saw its largest ever quarterly revenue in 2018 Q3.  He did not disclose how much of that was spent on the game Fortnite.
  • Cook noted that this past quarter saw all-time highs for both the number of monthly active users of the Messages app and for the number of FaceTime calls made.  If my son is an accurate guidepost, then a lot of those text messages and FaceTime calls are the result of kids being on summer vacation.
  • In the first three quarters of fiscal 2018, there were over 100 billion Siri requests.
  • Here in New Orleans, the two major pharmacies are Walgreen's and CVS.  One of the reasons that I typically choose Walgreen's is that it works great with Apple Pay.  But Cook announced that this Fall, Apple Pay will start to be accepted at CVS (and 7-Eleven too).
  • Cook said that when iOS 12 comes out, the iPhone will be noticeably faster.  The camera on the iPhone will launch up to 70% faster, the keyboard will appear up to 50% faster, and apps will be able to launch up to twice as fast.
  • Cook discussed the impact of President Trump's recent trade war.  He said that tariffs are "a tax on the consumer and wind up resulting in lower economic growth."  Having said that, Cook said that none of Apple's products were directly affected by three recent tariffs, and that Apple was still evaluating another one.  Cook concluded by saying that he was "optimistic that the countries will get through this, and we are hoping that calm heads prevail."
  • Everyone knows that Apple is now developing TV shows and movies and that it will at some point have some service to announce.  Cook said that he wasn't yet ready to share the details, but that he "couldn't be more excited about what's going on there, and we've got great talent in the area that we've sourced from different places, and [we] feel really good about what we will eventually offer."
  • Over 50 million people are now using Apple Music, although an (undisclosed) number of those are in a free trial period.
Categories: iPhone Web Sites

IBM Power System L922 Technical Overview and Introduction

IBM Redbooks Site - Tue, 07/31/2018 - 09:30
Redpaper, published: Tue, 31 Jul 2018

This IBM® Redpaper™ publication is a comprehensive guide covering the IBM Power System L922 (9008-22L) server, which was designed for data-intensive workloads such as databases and analytics in the Linux operating system.

Categories: Technology

IBM Spectrum Scale Immutability Introduction, Configuration Guidance, and Use Cases

IBM Redbooks Site - Mon, 07/30/2018 - 09:30
Redpaper, published: Mon, 30 Jul 2018

This IBM Redpaper™ publication introduces the IBM Spectrum Scale immutability function.

Categories: Technology

Machine Learning with Business Rules on IBM Z: Acting on Your Insights

IBM Redbooks Site - Fri, 07/27/2018 - 09:30
Redpaper, published: Fri, 27 Jul 2018

This Redpaper introduces the integration between two IBM products that you might like to consider when implementing a modern agile solution on your Z systems.

Categories: Technology

IBM Z Integration Guide for the Hybrid Cloud and API Economy

IBM Redbooks Site - Fri, 07/27/2018 - 09:30
Redpaper, published: Fri, 27 Jul 2018

Today, organizations are responding to market demands and regulatory requirements faster than ever by extending their applications and data to new digital applications.

Categories: Technology

In the news

iPhone J.D. - Fri, 07/27/2018 - 01:48

As noted by Juli Clover of MacRumors, Google's Street View app for iOS was updated this week to support the larger screen of the iPhone X.  I've had this app for a while, but this update caused me to try it out again this week, and it is amazing how powerful it is.  Enter any address, hold up your iPhone and tap the street view image and then tap the compass button at the top right, and you can move your iPhone around and "see" the area almost as if you were standing there at the address.  For an even more immersive experience, place your iPhone in an inexpensive Google Cardboard device.  Choose some interesting locations like in front of the Eiffel Tower in Paris or in front of the Lincoln Memorial in Washington, DC for some free virtual reality tourism.  And now, the news of note from the past week:

  • Chicago attorney John Voorhees is also an app developer and an editor at MacStories, and he was recently interviewed by Filip Brož of the Czechoslovakian website iPure.
  • A post on the GoodNotes blog provides tips for taking electronic notes at a conference.
  • William Gallagher of AppleInsider provides an overview of all of the ways to create text on an iPad:  text editors, note-taking apps, and word processors.
  • If you want an app to help you remember things which is a little more powerful than the built-in Reminders app, Federico Viticci of MacStories reviews the GoodTasks app.
  • Rosemary Orchard discusses some useful apps which run within the Messages app.  To be honest, the idea of running a mini-app within Messages still seems a little strange to me, so I haven't really explored this very much.
  • Chance Miller of 9to5Mac notes that Carrot Weather, my favorite weather app, was recently updated to add the ability to provide hurricane tracker notifications.  Like most folks who live in the Gulf South, I'd rather not be thinking about hurricanes, but we are definitely getting closer to the peak season.  (Hurricane Katrina made landfall` on August 29, 2005.)
  • Ian Fuchs of Cult of Mac reviews Documents by Readdle, a very useful app.
  • Drew Coffman of The Sweet Setup reviews the Lutron Caseta dimmer switch, a HomeKit-compatible light switch that I use throughout my house and which I really like.  (My review.)  I also see that the Lutron Smart Bridge, which I bought for over $100, is now $79.95 on Amazon.
  • And finally, Apple released a new video advertisement for the iPhone X which shows off its computing prowess at running powerful games.  The ad is called Unleash.  As John Gruber of Daring Fireball noted, it seems strange for Apple to release a new ad for the iPhone X when, presumably, the successor to the iPhone X will be unveiled in two months.  Regardless, it's a neat video:

Categories: iPhone Web Sites

Drawing Outside the Box: Precision Issues in Graphic Libraries

Google Project Zero - Thu, 07/26/2018 - 12:47
By Mark Brand and Ivan Fratric, Google Project Zero
In this blog post, we are going to write about a seldom seen vulnerability class that typically affects graphic libraries (though it can also occur in other types of software). The root cause of such issues is using limited precision arithmetic in cases where a precision error would invalidate security assumptions made by the application.
While we could also call other classes of bugs precision issues, namely integer overflows, the major difference is: with integer overflows, we are dealing with arithmetic operations where the magnitude of the result is too large to be accurately represented in the given precision. With the issues described in this blog post, we are dealing with arithmetic operations where the magnitude of the result or a part of the result is too small to be accurately represented in the given precision.
These issues can occur when using floating-point arithmetic in operations where the result is security-sensitive, but, as we’ll demonstrate later, can also occur in integer arithmetic in some cases.
Let’s look at a trivial example:
 float a = 100000000;  float b = 1;  float c = a + b;
If we were making the computation with arbitrary precision, the result would be 100000001. However, since float typically only allows for 24 bits of precision, the result is actually going to be 100000000. If an application makes the normally reasonable assumption that a > 0 and b > 0 implies that a + b > a, then this could lead to issues.
In the example above, the difference between a and b is so significant that b completely vanishes in the result of the calculation, but precision errors also happen if the difference is smaller, for example
 float a = 1000;  float b = 1.1111111;  float c = a + b;
The result of the above computation is going to be 1001.111084 and not 1001.1111111 which would be the accurate result. Here, only a part of b is lost, but even such results can sometimes have interesting consequences.
While we used the float type in the above examples, and in these particular examples using double would result in more accurate computation, similar precision errors can happen with double as well.
In the remainder of this blog post, we are going to show several examples of precision issues with security impact. These issues were independently explored by two Project Zero members: Mark Brand, who looked at SwiftShader, a software OpenGL implementation used in Chrome, and Ivan Fratric, who looked at the Skia graphics library, used in Chrome and Firefox. SwiftShaderSwiftShader is “a high-performance CPU-based implementation of the OpenGL ES and Direct3D 9 graphics APIs”. It’s used in Chrome on all platforms as a fallback rendering option to work around limitations in graphics hardware or drivers, allowing universal use of WebGL and other advanced javascript rendering APIs on a far wider range of devices.
The code in SwiftShader needs to handle emulating a wide range of operations that would normally be performed by the GPU. One operation that we commonly think of as essentially “free” on a GPU is upscaling, or drawing from a small source texture to a larger area, for example on the screen. This requires computing memory indexes using non-integer values, which is where the vulnerability occurs.
As noted in the original bug report, the code that we’ll look at here is not quite the code which is actually run in practice - SwiftShader uses an LLVM-based JIT engine to optimize performance-critical code at runtime, but that code is more difficult to understand than their fallback implementation, and both contain the same bug, so we’ll discuss the fallback code. This code is the copy-loop used to copy pixels from one surface to another during rendering:
 source->lockInternal((int)sRect.x0, (int)sRect.y0, sRect.slice, sw::LOCK_READONLY, sw::PUBLIC);
 dest->lockInternal(dRect.x0, dRect.y0, dRect.slice, sw::LOCK_WRITEONLY, sw::PUBLIC);

 float w = sRect.width() / dRect.width();
 float h = sRect.height() / dRect.height();

 const float xStart = sRect.x0 + 0.5f * w;
 float y = sRect.y0 + 0.5f * h;
 float x = xStart;

 for(int j = dRect.y0; j < dRect.y1; j++)
   x = xStart;

   for(int i = dRect.x0; i < dRect.x1; i++)
     // FIXME: Support RGBA mask
     dest->copyInternal(source, i, j, x, y, options.filter);

     x += w;

   y += h;


So - what highlights this code as problematic? We know prior to entering this function that all the bounds-checking has already been performed, and that any call to copyInternal with (i, j) in dRect and (x, y) in sRect will be safe.
The examples in the introduction above show cases where the resulting precision error means that a rounding-down occurs - in this case that wouldn’t be enough to produce an interesting security bug. Can we cause floating-point imprecision to result in a larger-than-correct value, leading to (x, y) values that are larger than expected?
If we look at the code, the intention of the developers is to compute the following:
 for(int j = dRect.y0; j < dRect.y1; j++)
   for(int i = dRect.x0; i < dRect.x1; i++)
   {      x = xStart + (i * w);      Y = yStart + (j * h);
     dest->copyInternal(source, i, j, x, y, options.filter);
If this approach had been used instead, we’d still have precision errors - but without the iterative calculation, there’d be no propagation of the error, and we could expect the eventual magnitude of the precision error to be stable, and in direct proportion to the size of the operands. With the iterative calculation as performed in the code, the errors start to propagate/snowball into a larger and larger error.
There are ways to estimate the maximum error in floating point calculations; and if you really, really need to avoid having extra bounds checks, using this kind of approach and making sure that you have conservative safety margins around those maximum errors might be a complicated and error-prone way to solve this issue. It’s not a great approach to identifying the pathological values that we want here to demonstrate a vulnerability; so instead we’ll take a brute-force approach.
Instinctively, we’re fairly sure that the multiplicative implementation will be roughly correct, and that the implementation with iterative addition will be much less correct. Given that the space of possible inputs is small (Chrome disallows textures with width or height greater than 8192), we can just run a brute force over all ratios of source width to destination width, comparing the two algorithms, and seeing where the results are most different. (Note that SwiftShader also limits us to even numbers). This leads us to the values of 5828, 8132; and if we compare the computations in this case (left side is the iterative addition, right side is the multiplication):
0:    1.075012 1.075012
1:    1.791687 1.791687
1000: 717.749878 717.749878   Up to here (at the precision shown) the values are still identical
1001: 718.466553 718.466553
2046: 1467.391724 1467.391724 At this point, the first significant errors start to occur, but note
2047: 1468.108398 1468.108521 that the "incorrect" result is smaller than the more precise one.
2856: 2047.898315 2047.898438
2857: 2048.614990 2048.614990 Here our two computations coincide again, briefly, and from here onwards
2858: 2049.331787 2049.331787 the precision errors consistently favour a larger result than the more
2859: 2050.048584 2050.048340 precise calculation.
8129: 5827.567871 5826.924805
8130: 5828.284668 5827.641602
8131: 5829.001465 5828.358398 The last index is now sufficiently different that int conversion results in an oob index.

(Note also that there will also be error in the “safe” calculation; it’s just that the lack of error propagation means that that error will remain directly proportional to the size of the input error, which we expect to be “small.”)
We can indeed see that, the multiplicative algorithm would remain within bounds; but that the iterative algorithm can return an index that is outside the bounds of the input texture!
As a result, we read an entire row of pixels past the end of our texture allocation - and this can be easily leaked back to javascript using WebGL. Stay tuned for an upcoming blog post in which we’ll use this vulnerability together with another unrelated issue in SwiftShader to take control of the GPU process from javascript.SkiaSkia is a graphics library used, among other places, in Chrome, Firefox and Android. In the web browsers it is used for example when drawing to a canvas HTML element using CanvasRenderingContext2D or when drawing SVG images. Skia is also used when drawing various other HTML elements, but canvas element and SVG images are more interesting from the security perspective because they enable more direct control over the objects being drawn by the graphic library.
The most complex type of object (and therefore, most interesting from the security perspective) that Skia can draw is a path. A path is an object that consists of elements such as lines, but also more complex curves, in particular quadratic or cubic splines.
Due to the way software drawing algorithms work in Skia, the precision issues are very much possible and quite impactful when they happen, typically leading to out-of-bounds writes.
To understand why these issues can happen, let’s assume you have an image in memory (represented as a buffer with size = width x height x color size). Normally, when drawing a pixel with coordinates (x, y) and color c, you would want to make sure that the pixel actually falls within the space of the image, specifically that 0 <= x < width and 0 <= y < height. Failing to check this could result in attempting to write the pixel outside the bounds of the allocated buffer. In computer graphics, making sure that only the objects in the image region are being drawn is called clipping.
So, where is the problem? Making a clip check for every pixel is expensive in terms of CPU cycles and Skia prides itself on speed. So, instead of making a clip check for every pixel, what Skia does is, it first makes the clip check on an entire object (e.g. line, path or any other type of object being drawn). Depending on the clip check, there are three possible outcomes:
  1. The object is completely outside of the drawing area: The drawing function doesn’t draw anything and returns immediately.

  1. The object is partially inside the drawing area: The drawing function proceeds with per-pixel clip enabled (usually by relying on SkRectClipBlitter).

  1. The entire object is in the drawing area: The drawing function draws directly into the buffer without performing per-pixel clip checks.

The problematic scenario is c) where the clip check is performed only per-object and the more precise, per-pixel checks are disabled. This means, if there is a precision issue somewhere between the per-object clip check and the drawing of pixels and if the precision issue causes the pixel coordinates to go outside of the drawing area, this could result in a security vulnerability.
We can see per-object clip checks leading to dropping per-pixel checks in several places, for example:
  • In hair_path (function for drawing a path without filling), clip is initially set to null (which disables clip checks). The clip is only set if the bounds of the path, rounded up and extended by 1 or 2 depending on the drawing options don’t fit in the drawing area. Extending the path bounds by 1 seems like a pretty large safety margin, but it is actually the least possible safe value because drawing objects with antialiasing on will sometimes result in drawing to nearby pixels.

  • In SkScan::FillPath (function for filling a path with antialiasing turned off), the bounds of the path are first extended by kConservativeRoundBias and rounded to obtain the “conservative” path bounds. A SkScanClipper object is then created for the current path. As we can see in the definition of SkScanClipper, it will only use SkRectClipBlitter if the x coordinates of the path bounds are outside the drawing area or if irPreClipped is true (which only happens when path coordinates are very large).

Similar patterns can be seen in other drawing functions.
Before we take a closer look at the issues, it is useful to quickly go over various number formats used by Skia:
  • SkScalar is a 32-bit floating point number

  • SkFDot6 is defined as an integer, but it is actually a fixed-point number with 26 bits to the left and 6 bits to the right of the decimal point. For example, SkFDot6 value of 0x00000001 represents the number 1/64.

  • SkFixed is also a fixed-point number, this time with 16 bits to the left and 16 bits to the right of the decimal point. For example, SkFixed value of 0x00000001 represents 1/(2**16)

Precision error with integer to float conversion
We discovered the initial problem when doing DOM fuzzing against Firefox last year. This issue where Skia wrote out-of-bounds caught our eye so we investigated further. It turned out the root cause was a discrepancy in the way Skia converted floating point to ints in several places. When making the per-path clip check, the lower coordinates (left and top of the bounding box) were rounded using this function:
static inline int round_down_to_int(SkScalar x) {    double xx = x;    xx -= 0.5;    return (int)ceil(xx);}
Looking at the code you see that it will return a number greater or equal to zero (which is necessary for passing the path-level clip check) for numbers that are strictly larger than -0.5. However, in another part of the code, specifically SkEdge::setLine if SK_RASTERIZE_EVEN_ROUNDING is defined (which is the case in Firefox), floats are rounded to integers differently, using the following function:
inline SkFDot6 SkScalarRoundToFDot6(SkScalar x, int shift = 0){    union {        double fDouble;        int32_t fBits[2];    } tmp;    int fractionalBits = 6 + shift;    double magic = (1LL << (52 - (fractionalBits))) * 1.5;
   tmp.fDouble = SkScalarToDouble(x) + magic;#ifdef SK_CPU_BENDIAN    return tmp.fBits[1];#else    return tmp.fBits[0];#endif}
Now let’s take a look at what these two functions return for a number -0.499. For this number, round_down_to_int returns 0 (which always passes the clipping check) and SkScalarRoundToFDot6 returns -32 which corresponds to -0.5, so we actually end up with a number that is smaller than the one we started with.
That’s not the only problem, though, because there’s another place where a precision error occurs in SkEdge::setLine.
Precision error when multiplying fractions
SkEdge::setLine calls SkFixedMul which is defined as:
static inline SkFixed(SkFixed a, SkFixed b) {    return (SkFixed)((int64_t)a * b >> 16);}
This function is for multiplying two SkFixed numbers. An issue comes up when using this function to multiply negative numbers. Let’s look at a small example. Let’s assume a = -1/(2**16) and b = 1/(2**16). If we multiply these two numbers on paper, the result is -1/(2**32). However, due to the way SkFixedMul works, specifically because the right shift is used to convert the result back to SkFixed format, the result we actually end up with is 0xFFFFFFFF which is SkFixed for  -1/(2**16). Thus, we end up with a result with a magnitude much larger than expected.
As the result of this multiplication is used by SkEdge::setLine to adjust the x coordinate of the initial line point here, we can use the issue in SkFixedMul to cause an additional error up to 1/64 of a pixel to go outside of the drawing area bounds.
By combining the previous two issues, it was possible to get the x coordinate of a line sufficiently small (smaller than -0.5), so that, when a fractional representation was rounded to an integer here, Skia attempted to draw at coordinates with x = -1, which is clearly outside the image bounds. This then led to an out-of-bounds write as can be seen in the original bug report. This bug could be exploited in Firefox by drawing an SVG image with coordinates as described in the previous section.
Floating point precision error when converting splines to line segments
When drawing paths, Skia is going to convert all non-linear curves (conic shapes, quadratic and cubic splines) to line segments. Perhaps unsurprisingly, these conversions suffer from precision errors.
The conversion of splines into line segments happen in several places, but the most susceptible to floating-point precision errors are hair_quad (used for drawing quadratic curves) and hair_cubic (used for drawing cubic curves). Both of these functions are called from hair_path, which we already mentioned above. Because (unsurprisingly), larger precision errors occur when dealing with cubic splines, we’ll only consider the cubic case here.
When approximating the spline, first the cubic coefficients are computed in SkCubicCoeff. The most interesting part is:
fA = P3 + three * (P1 - P2) - P0;fB = three * (P2 - times_2(P1) + P0);fC = three * (P1 - P0);fD = P0;
Where P1, P2 and P3 are input points and fA, fB, fC and fD are output coefficients. The line segment points are then computed in hair_cubic using the following code
const Sk2s dt(SK_Scalar1 / lines);Sk2s t(0);
Sk2s A = coeff.fA;Sk2s B = coeff.fB;Sk2s C = coeff.fC;Sk2s D = coeff.fD;for (int i = 1; i < lines; ++i) {    t = t + dt;    Sk2s p = ((A * t + B) * t + C) * t + D;    p.store(&tmp[i]);}
Where p is the output point and lines is the number of line segments we are using to approximate the curve. Depending on the length of the spline, a cubic spline can be approximated with up to 512 lines.
It is obvious that the arithmetic here is not going to be precise. As identical computations happen for x and y coordinates, let’s just consider the x coordinate in the rest of the post.
Let’s assume the width of the drawing area is 1000 pixels. Because hair_path is used for drawing path with antialiasing turned on, it needs to make sure that all points of the path are between 1 and 999, which is done in the initial, path-level clip check. Let’s consider the following coordinates that all pass this check:
p0 = 1.501923p1 = 998.468811p2 = 998.998779p3 = 999.000000
For these points, the coefficients are as follows
a = 995.908203b = -2989.310547c = 2990.900879d = 1.501923
If you do the same computation in larger precision, you’re going to notice that the numbers here aren’t quite correct. Now let’s see what happens if we approximate the spline with 512 line segments. This results in 513 x coordinates:
0: 1.5019231: 7.3321302: 13.1395743: 18.9243014: 24.6863565: 30.425781...500: 998.986389501: 998.989563502: 998.992126503: 998.994141504: 998.995972505: 998.997314506: 998.998291507: 998.999084508: 998.999695509: 998.999878510: 999.000000511: 999.000244512: 999.000000
We can see that the x coordinate keeps growing and at point 511 clearly goes outside of the “safe” area and grows larger than 999.
As it happens, this isn’t sufficient to trigger an out-of-bounds write, because, due to how drawing antialiased lines works in Skia, we need to go at least 1/64 of a pixel outside of the clip area for it to become a security issue. However, an interesting thing about the precision errors in this case is that the larger the drawing area, the larger the error that can happen.
So let’s instead consider a drawing area of 32767 pixels (maximum canvas size in Chrome). The initial clipping check then checks that all path points are in the interval [1, 32766]. Now let’s consider the following points:
p0 = 1.7490234375p1 = 32765.9902343750p2 = 32766.000000p3 = 32766.000000
The corresponding coefficients
a = 32764.222656b = -98292.687500c = 98292.726562d = 1.749023
And the corresponding line approximation
0: 1.749023431: 193.3522952: 384.2071233: 574.3149414: 763.6772465: 952.295532…505: 32765.925781506: 32765.957031507: 32765.976562508: 32765.992188509: 32766.003906510: 32766.003906511: 32766.015625512: 32766.000000
You can see that we went out-of-bounds significantly more at index 511.
Fortunately for Skia and unfortunately for aspiring attackers, this bug can’t be used to trigger memory corruption, at least not in the up-to-date version of skia. The reason is SkDrawTiler. Whenever Skia draws using SkBitmapDevice (as opposed to using a GPU device) and the drawing area is larger than 8191 pixels in any dimension, instead of drawing the whole image at once, Skia is going to split it into tiles of size (at most) 8191x8191 pixels. This change was made in March, not for security reasons, but to be able to support larger drawing surfaces. However, it still effectively prevented us from exploiting this issue and will also prevent exploiting other cases where a surface larger than 8191 is required to reach the precision error of a sufficient magnitude.
Still, this bug was exploitable before March and we think it nicely demonstrates the concept of precision errors.
Integer precision error when converting splines to line segments
There is another place where splines are approximated as line segments when drawing (in this case: filling) paths that was also affected by a precision error, in this case an exploitable one. Interestingly, here the precision error wasn’t in floating-point but rather in fixed-point arithmetic.
The error happens in SkQuadraticEdge::setQuadraticWithoutUpdate and SkCubicEdge::setCubicWithoutUpdate. For simplicity, we are again going to concentrate just on the cubic spline version and, again, only on the x coordinate.
In SkCubicEdge::setCubicWithoutUpdate, the curve coordinates are first converted to SkFDot6 type (integer with 6 bits used for fraction). After that, parameters corresponding to the first, second and third derivative of the curve at the initial point are going to be computed:
SkFixed B = SkFDot6UpShift(3 * (x1 - x0), upShift);SkFixed C = SkFDot6UpShift(3 * (x0 - x1 - x1 + x2), upShift);SkFixed D = SkFDot6UpShift(x3 + 3 * (x1 - x2) - x0, upShift);
fCx     = SkFDot6ToFixed(x0);fCDx    = B + (C >> shift) + (D >> 2*shift);    // biased by shiftfCDDx   = 2*C + (3*D >> (shift - 1));           // biased by 2*shiftfCDDDx  = 3*D >> (shift - 1);                   // biased by 2*shift
Where x0, x1, x2 and x3 are x coordinates of the 4 points that define the cubic spline and shift and upShift depend on the length of the curve (this corresponds to the number of linear segments the curve is going to be approximated in). For simplicity, we can assume shift = upShift = 6 (maximum possible values).
Now let’s see what happens for some very simple input values:
x0 = -30x1 = -31x2 = -31x3 = -31
Note that x0, x1, x2 and x3 are of the type SkFDot6 so value -30 corresponds to -0.46875 and -31 to -0.484375. These are close to -0.5 but not quite and are thus perfectly safe when rounded. Now let’s examine the values of the computed parameters:
B = -192C = 192D = -64
fCx = -30720fCDx = -190fCDDx = 378fCDDDx = -6
Do you see where the issue is? Hint: it’s in the formula for fCDx.
When computing fCDx (first derivation of a curve), the value of D needs is right-shifted by 12. However, D is too small to do that precisely, and since D is negative, the right shift
D >> 2*shift
Is going to result in -1, which is larger in magnitude than the intended result. (Since D is of type SkFixed its actual value is -0.0009765625 and the shift, when interpreted as division by 4096, would result in -2.384185e-07). Because of this, the whole fCDx ends up as a larger negative value than it should (-190 vs. -189.015).
Afterwards, the value of fCDx gets used when calculating the x value of line segments. This happens in SkCubicEdge::updateCubic on this line:
newx    = oldx + (fCDx >> dshift);
The x values, when approximating the spline with 64 line segments (maximum for this algorithm), are going to be (expressed as index, integer SkFixed value and the corresponding floating point value):
index raw      interpretation0:    -30720   -0.468751:    -30768   -0.4694822:    -30815   -0.4702003:    -30860   -0.4708864:    -30904   -0.4715585:    -30947   -0.472214...31:   -31683   -0.48344432:   -31700   -0.48370433:   -31716   -0.48394834:   -31732   -0.48419235:   -31747   -0.48442136:   -31762   -0.48465037:   -31776   -0.48486338:   -31790   -0.485077...60:   -32005   -0.48835861:   -32013   -0.48848062:   -32021   -0.48860263:   -32029   -0.48872464:   -32037   -0.488846
You can see that for the 35th point, the x value (-0.484421) ends up being smaller than the smallest input point (-0.484375) and the trend continues for the later points. This value would still get rounded to 0 though, but there is another problem.
The x values computed in SkCubicEdge::updateCubic are passed to SkEdge::updateLine, where they are converted from SkFixed type to SkFDot6 on the following lines:
x0 >>= 10;x1 >>= 10;
Another right shift! And when, for example, SkFixed value -31747 gets shifted we end up with SkFDot6 value of -32 which represents -0.5.
At this point we can use the same trick described above in the “Precision error when multiplying fractions” section to go smaller than -0.5 and break out of the image bounds. In other words, we can make Skia draw to x = -1 when drawing a path.
But, what can we do with it?
In general, given that Skia allocates image pixels as a single allocation that is organized row by row (as most other software would allocate bitmaps), there are several cases of what can happen with precision issues. If we assume an width x height image and that we are only able to go one pixel out of bounds:
  1. Drawing to y = -1 or y = height immediately leads to heap out-of-bounds write
  2. Drawing to x = -1 with y = 0 immediately leads to a heap underflow of 1 pixel
  3. Drawing to x = width with y = height - 1 immediately leads to heap overflow of 1 pixel
  4. Drawing to x = -1 with y > 0 leads to a pixel “spilling” to the previous image row
  5. Drawing to x = height with y < height-1 leads to a pixel “spilling” to the next image row

What we have here is scenario d) - unfortunately we can’t draw to x = 1 with y = 0 because the precision error needs to accumulate over the growing values of y.
Let’s take a look at the following example SVG image:
<svg width="100" height="100" xmlns="http://www.w3.org/2000/svg"><style>body { margin-top: 0px; margin-right: 0px; margin-bottom: 0px; margin-left: 0px}</style><path d="M -0.46875 -0.484375 C -0.484375 -0.484375, -0.484375 -0.484375, -0.484375 100 L 1 100 L 1 -0.484375" fill="red" shape-rendering="crispEdges" /></svg>
If we render this in an unpatched version of Firefox what we see is shown in the following image. Notice how the SVG only contains coordinates on the left side of the screen, but some of the red pixels get drawn on the right. This is because, due to the way images are allocated, drawing to x = -1 and y = row is equal to drawing to x = width - 1 and y = row - 1.

Opening an SVG image that triggers a Skia precision issue in Firefox. If you look closely you’ll notice some red pixels on the right side of the image. How did those get there? :)
Note that we used Mozilla Firefox and not Google Chrome because, due to SVG drawing internals (specifically: Skia seems to draw the entire image at once, while Chrome uses additional tiling) it is easier to demonstrate the issue in Firefox. However, both Chrome and Firefox were equally affected by this issue.
But, other than drawing a funny image, is there real security impact to this issue? Here, SkARGB32_Shader_Blitter comes to the rescue (SkARGB32_Shader_Blitter is used whenever shader effects are applied to a color in Skia). What is specific about SkARGB32_Shader_Blitter is that it allocates a temporary buffer of the same size as a single image row. When SkARGB32_Shader_Blitter::blitH is used to draw an entire image row, if we can make it draw from x = -1 to x = width - 1 (alternately from x = 0 to x = width), it will need to write width + 1 pixels into a buffer that can only hold width pixels, leading to a buffer overflow as can be seen in the ASan log in the bug report.
Note how the PoCs for Chrome and Firefox contain SVG images with a linearGradient element - the linear gradient is used specifically to select SkARGB32_Shader_Blitter instead of drawing pixels to the image directly, which would only result in pixels spilling to the previous row.
Another specific of this issue is that it can only be reached when drawing (more specifically: filling) paths with antialiasing turned off. As it is not currently possible to draw paths to a HTML canvas elements with antialiasing off (there is an imageSmoothingEnabled property but it only applies to drawing images, not paths), an SVG image with shape-rendering="crispEdges" must be used to trigger the issue.
All precision issues we reported in Skia were fixed by increasing kConservativeRoundBias. While the current bias value is large enough to cover the maximum precision errors we know about, we should not dismiss the possibility of other places where precision issues can occur.ConclusionWhile precision issues, such as described in this blog post, won’t be present in most software products, where they are present they can have quite serious consequences. To prevent them from occurring:
  • Don’t use floating-point arithmetic in cases where the result is security-sensitive. If you absolutely have to, then you need to make sure that the maximum possible precision error cannot be larger than some safety margin. Potentially, interval arithmetic could be used to determine the maximum precision error in some cases. Alternately, perform security checks on the result rather than input.

  • With integer arithmetic, be wary of any operations that can reduce the precision of the result, such as divisions and right shifts.

When it comes to finding such issues, unfortunately, there doesn’t seem to be a great way to do it. When we started looking at Skia, initially we wanted to try using symbolic execution on the drawing algorithms to find input values that would lead to drawing out-of-bounds, as, on the surface, it seemed this is a problem symbolic execution would be well suited for. However, in practice, there were too many issues: most tools don’t support floating point symbolic variables and, even when running against just the integer parts of the simplest line drawing algorithm, we were unsuccessful in completing the run in a reasonable time (we were using KLEE with STP and Z3 backends).
In the end, what we ended up doing was a combination of the more old-school methods: manual source review, fuzzing (especially with values close to image boundaries) and, in some cases, when we already identified potentially problematic areas of code, even bruteforcing the range of all possible values.
Do you know of other instances where precision errors resulted in security issues? Let us know about them in the comments.
Categories: Security

Introduction to IBM Common Data Provider for z Systems

IBM Redbooks Site - Thu, 07/26/2018 - 09:30
Redpaper, published: Thu, 26 Jul 2018

IBM Common Data Provider for z Systems collects, filters, and formats IT operational data in near real-time and provides that data to target analytics solutions.

Categories: Technology

IBM Power Systems S922, S914, and S924 Technical Overview and Introduction

IBM Redbooks Site - Thu, 07/26/2018 - 09:30
Redpaper, published: Thu, 26 Jul 2018

This IBM® Redpaper™ publication is a comprehensive guide that covers the IBM Power System S922 (9009-22A), IBM Power System S914 (9009-41A), and IBM Power System S924 (9009-42A) servers that support IBM AIX®, IBM i, and Linux operating systems.

Categories: Technology

1Password secure notes, now with Markdown formatting

iPhone J.D. - Wed, 07/25/2018 - 22:53

The main reason to use a password manager is to create, store, and automatically type usernames and passwords.  But one side benefit of the major password manager apps such as 1Password and LastPass is the ability to store secure notes.  This is a digital notepad where you can store some text, much like you would using the built-in Notes app.  The difference is that these notes are safely stored in the password manager app, which is secured with your complex password (or your fingerprint or your face if you have that enabled).  I like this feature because there are rare instances in which someone else has access to my iPhone or iPad.  I wouldn't let them use my device if I didn't trust the person, but even so, I don't want that person accessing my truly confidential information, even accidentally.  Someone else using my iPad could open the Notes app and see the numerous notes that I have stored there, things like grocery and packing lists, the members of my daughter's soccer team, etc.  But the person wouldn't be able to open my 1Password app, and thus couldn't see my truly private notes.

What type of information do I store in secure notes?  I have some medical information about me and family members in there.  I have birthday present ideas.  I have financial information such as a history of salaries for me and my staff members.  I have a list of all of my former addresses, going all the way back to high school.  And I have some confidential information related to my cases, which will sometimes include items like settlement authority.  Having all of this important, confidential information in one secure location is incredibly valuable.  If you use a password manager and don't currently take advantage of the secure notes feature, I encourage you to do so.

I've been thinking about secure notes for the past few days because 1Password, my preferred password manager, recently added the ability to use Markdown in secure notes.  This means that you can add some simple symbols to your text to format the text.  For example, if you want something in a note to be bold, you can just begin and end it with two asterisks or two underline symbols.  Thus, if you type something like this:

**The Title**

__Another Title__

It will be formatted in 1Password to look like this:

The Title

Another Title

You can also use one underline symbol before and after to do italics, three dashes to add a line, etc.  1Password lists some common Markdown commands on this page, and if you want a more comprehensive description of Markdown you can view this page created by John Gruber, who created Markdown many years ago.

For those of you who used WordPerfect way back when, you may remember how WordPerfect fans loved the reveal codes feature, making it easy to see the commands that told the computer to format your text.  Markdown is the same idea.  When you are in the edit mode, you see the symbols like ** but when you are in the normal view mode, you see the end result such as bold text.  What all of this means is that it takes virtually no time to make your notes look even nicer and easier to read in 1Password.

I'd love to show you some examples of how I am using Markdown in my secure notes, but obviously my secure notes are private so I am not going to post them on a public website.  Instead, I created two sample secure notes in 1Password.  One is the Preamble to the Constitution.  The other one is something I copied from my Notes app.  Over the last year or so, my kids and I have been working our way through the James Bond movies.  Not all of them — I selected what I think are the better ones.  (Feel free to disagree with my choices.)  I have a list to remind me of what we have already seen and what is next.  Here is what part of each note looks like when I am in the edit mode in 1Password:


And here is what the notes look like with the simple formatting applied (bold text, a numbered list, and a dividing line).  So this is what you would see when you normally view the note:


Looking at the James Bond list reminds me that the next movie up for us is Goldeneye, our first Pierce Brosnan movie.  I remember being excited when he (finally) took over the role because I used to watch the Remington Steele TV show in the 1980s.  Okay, enough about Bond, let's get back to 1Password now.

Markdown formatting looks great.  I wish that 1Password would add the ability to adjust the text size — the text is crisp and clear on my iPhone X and my iPad Pro, but I wish that the text could be larger — and perhaps that will be added in the future.  But my notes are much easier to read with formatting than they are without formatting.

If you use 1Password and you have been waiting for an excuse to create some secure notes, perhaps this can be the impetus for you to start using this feature.  And if you are not yet using a password manager, now you have yet another reason that you should be doing so.

Categories: iPhone Web Sites

Building a SAN-less Private Cloud with IBM PowerVM and IBM PowerVC

IBM Redbooks Site - Tue, 07/24/2018 - 09:30
Redpaper, published: Tue, 24 Jul 2018

This IBM® Redpaper™ publication describes a software-defined infrastructure (SDI) solution with IBM PowerVC.

Categories: Technology

IBM Power System AC922 Technical Overview and Introduction

IBM Redbooks Site - Mon, 07/23/2018 - 09:30
Redpaper, published: Mon, 23 Jul 2018

This IBM® Redpaper™ publication is a comprehensive guide that covers the IBM Power System AC922 server (8335-GTH and 8335-GTX models).

Categories: Technology

IBM Software-Defined Storage Guide

IBM Redbooks Site - Sat, 07/21/2018 - 09:30
Redpaper, published: Sat, 21 Jul 2018

Today, new business models in the marketplace coexist with traditional ones and their well-established IT architectures.

Categories: Technology

In the news

iPhone J.D. - Fri, 07/20/2018 - 19:04

I have been using handheld devices since the late 1980s, starting with a Sharp Wizard, then numerous Palm and BlackBerry devices, and finally a Palm Treo 650.  But 10 years ago on July 22, 2018, I started using an iPhone 3G, and it was vastly superior to anything I had used before.  (This post from three years ago shows the last important email I ever read on my Palm Treo 650.)  It was the second generation of the iPhone and the first iPhone that was truly useful for attorneys becuase we could use faster 3G data, the App Store, and Microsoft Exchange.  Stephen Hackett wrote a post for MacStories this week looking back at the iPhone 3G.  As much as I loved that iPhone 3G at the time, it is amazing to think of how far the iPhone has come in the past 10 years, and it is hard to even imagine what kind of handheld device I'll be using in another 10 years.  And now, the news of note from the past week:

Categories: iPhone Web Sites

Webmentions: Enabling Better Communication on the Internet

A list Apart development site - Thu, 07/19/2018 - 09:00

Over 1 million Webmentions will have been sent across the internet since the specification was made a full Recommendation by the W3C—the standards body that guides the direction of the web—in early January 2017. That number is rising rapidly, and in the last few weeks I’ve seen a growing volume of chatter on social media and the blogosphere about these new “mentions” and the people implementing them.

So what are Webmentions and why should we care?

While the technical specification published by the W3C may seem incomprehensible to most, it’s actually a straightforward and extremely useful concept with a relatively simple implementation. Webmentions help to break down some of the artificial walls being built within the internet and so help create a more open and decentralized web. There is also an expanding list of major web platforms already supporting Webmentions either natively or with easy-to-use plugins (more on this later).

Put simply, Webmention is a (now) standardized protocol that enables one website address (URL) to notify another website address that the former contains a reference to the latter. It also allows the latter to verify the authenticity of the reference and include its own corresponding reference in a reciprocal way. In order to understand what a big step forward this is, a little history is needed.

The rise of @mentions

By now most people are familiar with the ubiquitous use of the “@” symbol in front of a username, which originated on Twitter and became known as @mentions and @replies (read “at mentions” and “at replies”). For the vast majority, this is the way that one user communicates with other users on the platform, and over the past decade these @mentions, with their corresponding notification to the receiver, have become a relatively standard way of communicating on the internet.

Tweet from Wiz Khalifa

Many other services also use this type of internal notification to indicate to other users that they have been referenced directly or tagged in a post or photograph. Facebook allows it, so does Instagram. Google+ has a variant that uses + instead of @, and even the long-form article platform Medium, whose founder Ev Williams also co-founded Twitter, quickly joined the @mentions party.

The biggest communications problem on the internet

If you use Twitter, your friend Alice only uses Facebook, your friend Bob only uses his blog on WordPress, and your pal Chuck is over on Medium, it’s impossible for any one of you to @mention another. You’re all on different and competing platforms, none of which interoperate to send these mentions or notifications of them. The only way to communicate in this way is if you all join the same social media platforms, resulting in the average person being signed up to multiple services just to stay in touch with all their friends and acquaintances.

Given the issues of privacy and identity protection, different use cases, the burden of additional usernames and passwords, and the time involved, many people don’t want to do this. Possibly worst of all, your personal identity on the internet can end up fragmented like a Horcrux across multiple websites over which you have little, if any, control.

Imagine if AT&T customers could only speak to other AT&T customers and needed a separate phone, account, and phone number to speak to friends and family on Verizon. And still another to talk to friends on Sprint or T-Mobile. The massive benefit of the telephone system is that if you have a telephone and service (from any one of hundreds or even thousands of providers worldwide), you can potentially reach anyone else using the network. Surely, with a basic architecture based on simple standards, links, and interconnections, the same should apply to the internet?

The solution? Enter Webmentions!

As mentioned earlier, Webmentions allow notifications between web addresses. If both sites are set up to send and receive them, the system works like this:

  1. Alice has a website where she writes an article about her rocket engine hobby.
  2. Bob has his own website where he writes a reply to Alice’s article. Within his reply, Bob includes the permalink URL of Alice’s article.
  3. When Bob publishes his reply, his publishing software automatically notifies Alice’s server that her post has been linked to by the URL of Bob’s reply.
  4. Alice’s publishing software verifies that Bob’s post actually contains a link to her post and then (optionally) includes information about Bob’s post on her site; for example, displaying it as a comment.

A Webmention is simply an @mention that works from one website to another!

If she chooses, Alice can include the full text of Bob’s reply—along with his name, photo, and his article’s URL (presuming he’s made these available)—as a comment on her original post. Any new readers of Alice’s article can then see Bob’s reply underneath it. Each can carry on a full conversation from their own websites and in both cases display (if they wish) the full context and content.

Using Webmentions, both sides can carry on a conversation where each is able to own a copy of the content and provide richer context.

User behaviors with Webmentions are a little different than they are with @mentions on Twitter and the like in that they work between websites in addition to within a particular website. They enable authors (of both the original content and the responses) to own the content, allowing them to keep a record on the web page where it originated, whether that’s a website they own or the third-party platform from which they chose to send it.

Interaction examples with Webmention

Webmentions certainly aren’t limited to creating or displaying “traditional” comments or replies. With the use of simple semantic microformats classes and a variety of parsers written in numerous languages, one can explicitly post bookmarks, likes, favorites, RSVPs, check-ins, listens, follows, reads, reviews, issues, edits, and even purchases. The result? Richer connections and interactions with other content on the web and a genuine two-way conversation instead of a mass of unidirectional links. We’ll take a look at some examples, but you can find more on the IndieWeb wiki page for Webmention alongside some other useful resources.


With Webmention support, one could architect a site to allow inline marginalia and highlighting similar to Medium.com’s relatively well-known functionality. With the clever use of URL fragments, which are well supported in major browsers, there are already examples of people who use Webmentions to display word-, sentence-, or paragraph-level marginalia on their sites. After all, aren’t inline annotations just a more targeted version of comments?

An inline annotation on the post “Hey Ev, what about mentions?,” in which Medium began to roll out their @mention functionality. Reads

As another example, and something that could profoundly impact the online news business, I might post a link on my website indicating I’ve read a particular article on, say, The New York Times. My site sends a “read” Webmention to the article, where a facepile or counter showing the number of read Webmentions received could be implemented. Because of the simplified two-way link between the two web pages, there is now auditable proof of interaction with the content. This could similarly work with microinteractions such as likes, favorites, bookmarks, and reposts, resulting in a clearer representation of the particular types of interaction a piece of content has received. Compared to an array of nebulous social media mini-badges that provide only basic counters, this is a potentially more valuable indicator of a post’s popularity, reach, and ultimate impact.


Building on the idea of using reads, one could extend Webmentions to the podcasting or online music sectors. Many platforms are reasonably good at providing download numbers for podcasts, but it is far more difficult to track the number of actual listens. This can have a profound effect on the advertising market that supports many podcasts. People can post about what they’re actively listening to (either on their personal websites or via podcast apps that could report the percentage of the episode listened to) and send “listen” Webmentions to pages for podcasts or other audio content. These could then be aggregated for demographics on the back end or even shown on the particular episode’s page as social proof of the podcast’s popularity.

For additional fun, podcasters or musicians might use Webmentions in conjunction with media fragments and audio or video content to add timecode-specific, inline comments to audio/video players to create an open standards version of SoundCloud-like annotations and commenting.

SoundCloud allows users to insert inline comments that dovetail with specific portions of audio. Reviews

Websites selling products or services could also accept review-based Webmentions that include star-based ratings scales as well as written comments with photos, audio, or even video. Because Webmentions are a two-way protocol, the reverse link to the original provides an auditable path to the reviewer and the opportunity to assess how trustworthy their review may be. Of course, third-party trusted sites might also accept these reviews, so that the receiving sites can’t easily cherry-pick only positive reviews for display. And because the Webmention specification includes the functionality for editing or deletion, the original author has the option to update or remove their reviews at any time.

Getting started with Webmentions Extant platforms with support

While the specification has only recently become a broad recommendation for use on the internet, there are already an actively growing number of content management systems (CMSs) and platforms that support Webmentions, either natively or with plugins. The simplest option, requiring almost no work, is a relatively new and excellent social media service called Micro.blog, which handles Webmentions out of the box. CMSs like Known and Perch also have Webmention functionality built in. Download and set up the open source software and you’re ready to go.

If you’re working with WordPress, there’s a simple Webmention plugin that will allow you to begin using Webmentions—just download and activate it. (For additional functionality when displaying Webmentions, there’s also the recommended Semantic Linkbacks plugin.) Other CMSs like Drupal, ProcessWire, Elgg, Nucleus CMS, Craft, Django, and Kirby also have plugins that support the standard. A wide variety of static site generators, like Hugo and Jekyll, have solutions for Webmention technology as well. More are certainly coming.

If you can compose basic HTML on your website, Aaron Parecki has written an excellent primer on “Sending Your First Webmention from Scratch.”

A weak form of Webmention support can be bootstrapped for Tumblr, WordPress.com, Blogger, and Medium with help from the free Bridgy service, but the user interface and display would obviously be better if they were supported fully and natively.

As a last resort, if you’re using Tumblr, WordPress.com, Wix, Squarespace, Ghost, Joomla, Magento, or any of the other systems without Webmention, file tickets asking them to support the standard. It only takes a few days of work for a reasonably experienced developer to build support, and it substantially improves the value of the platform for its users. It also makes them first-class decentralized internet citizens.

Webmentions for developers

If you’re a developer or a company able to hire a developer, it is relatively straightforward to build Webmentions into your CMS or project, even potentially open-sourcing the solution as a plugin for others. For anyone familiar with the old specifications for pingback or trackback, you can think of Webmentions as a major iteration of those systems, but with easier implementation and testing, improved performance and display capabilities, and decreased spam vulnerabilities. Because the specification supports editing and deleting Webmentions, it provides individuals with more direct control of their data, which is important in light of new laws like GDPR.

In addition to reading the specification, as mentioned previously, there are multiple open source implementations already written in a variety of languages that you can use directly, or as examples. There are also a test suite and pre-built services like Webmention.io, Telegraph, mention-tech, and webmention.herokuapp.com that can be quickly leveraged.

Maybe your company allows employees to spend 20% of their time on non-specific projects, as Google does. If so, I’d encourage you to take the opportunity to fbuild Webmentions support for one or more platforms—let’s spread the love and democratize communication on the web as fast as we can!

And if you already have a major social platform but don’t want to completely open up to sending and receiving Webmentions, consider using Webmention functionality as a simple post API. I could easily see services like Twitter, Mastodon, or Google+ supporting the receiving of Webmentions, combined with a simple parsing mechanism to allow Webmention senders to publish syndicated content on their platform. There are already several services like IndieNews, with Hacker News-like functionality, that allow posting to them via Webmention.

If you have problems or questions, I’d recommend joining the IndieWeb chat room online via IRC, web interface, Slack, or Matrix to gain access to further hints, pointers, and resources for implementing a particular Webmention solution.

The expansion of Webmentions

The big question many will now have is Will the traditional social media walled gardens like Facebook, Twitter, Instagram, and the like support the Webmention specification?

At present, they don’t, and many may never do so. After all, locking you into their services is enabling them to leverage your content and your interactions to generate income. However, I suspect that if one of the major social platforms enabled sending/receiving Webmentions, it would dramatically disrupt the entire social space.

In the meantime, if your site already has Webmentions enabled, then congratulations on joining the next revolution in web communication! Just make sure you advertise the fact by using a button or badge. You can download a copy here.

Categories: Technology

Apple previews new emoji coming in iOS 12

iPhone J.D. - Tue, 07/17/2018 - 01:11

After all of the news from yesterday, and indeed the past week, I think we all deserve an escape from reality.  Fortunately, Apple has some nice pictures for us to look at.  To celebrate World Emoji Day today, Apple is previewing some of the new emoji characters which will be a part of iOS 12 this Fall.  The ideas for new emoji are considered and approved by the Unicode Consortium, and the new emoji in iOS 12 come from the Consortium's Emoji Version 11.0, approved earlier this year.  The Consortium has general rules on what each emoji is supposed to look like, but each company has a lot of flexibility in the specific designs, which is why emoji can look different on iPhone, Android, your computer, etc.  As always, the designers at Apple have done a really nice job with these.

First, we have a male and female superhero, the infinity symbol, and a Nazar Amulet (which Emojipedia explains is an "eye-shaped amulet believed to protect against the 'evil eye'" and which is common in Turkey:

Next we have a parrot, lobster, kangaroo, and peacock, which are some of the new animals in iOS 12 (along with a racoon, llamo, hippotamus, badger, swan, and mosquito):

iOS 12 will include many more food items.  Here are leafy green, mango, moon cake (a Chinese pastry), and cupcake.  Other new food items will include a bagel and salt.

There are new faces in iOS 12.  Here are partying face, pleading face, cold face, and smiling face with three hearts.  The other new faces are hot face and woozy face.

The new emoji also contain more hair options for both sexes:  red hair, curly hair, bald, and white hair, each of which is presented in a generic format plus five different skin tones.  For example, here are larger versions of the six different versions of the new female with red hair:

Here are all of the new hairstyles and colors:

Of course, if you have a new iPhone such as an iPhone X, you will also be able to use Apple's new Memoji feature to create an emoji that looks like yourself.  To show this off, Apple has changed the page of the Apple website that shows the faces of Apple's executives, and today instead of photographs it includes Memoji.  Look at the page for all of the new faces, but here are some of them:

There are also new objects in iOS 12.  Here are yarn, softball, and test tube.  Other new objects include compass, brick, skateboard, luggage, firecracker, red gift envelope, flying disc, lacrosse, jigsaw, teddy bear, chess pawn, abacus, receipt, toolbox, magnet, petri dish, DNA, fire extinguisher, lotion bottle, thread, safety pin, broom, basket, roll of toilet paper, soap, sponge and pirate flag.

In all, Apple says that there are over 70 new emoji characters.  However, according to Emojipedia, the actual number is closer to 150 when gender and skin tone are taken into account.

Categories: iPhone Web Sites


Subscribe to www.hdgonline.net aggregator