584 stories
·
8 followers

Project Memory

1 Share

For a series of events that I’m not entirely sure the start of, I started fixing some links on my old blog posts, fixing some links that got broken, most of which I ended up having to find on the Wayback Archive. While looking at that, I ended up finding some content for my very old blog. A one that was hosted on Blogspot, written in Italian only, and seriously written by an annoying brat that needed to learn something about life. Which I did, of course. The story of that blog is for a different time and post, for now I’ll actually focus on a different topic.

When I started looking at this, I ended up going through a lot of my blogposts and updated a number of broken links, either by linking to the Wayback machine or by removing the link. I focused on those links that can easily be grepped for, which turns out to be a very good side effect of having migrated to Hugo.

This meant, among other things, removing references to identi.ca (which came to my mind because of all the hype I hear about Mastodon nowadays), removing links to my old “Hire me!” page, and so on. And that’s where things started showing a pattern.

I ended up updating or removing links to Berlios, Rubyforge, Gitorious, Google Code, Gemcutter, and so on.

For many of these, turned out I don’t even have a local copy (at hand at least) of some of my smaller projects (mostly the early Ruby stuff I’ve done). But I almost certainly have some of that data in my backups, some of which I actually have in Dublin and want to start digging into at some point soon. Again, this is a story for a different time.

The importance to the links to those project management websites is that for many projects, those pages were all that you had about them. And for some of those, all the important information was captured by those services.

Back when I started contributing to free software projects, SourceForge was the badge of honor of being an actual project: it would give you space to host a website, as well as the ability to have source code repositories and websites. And this was the era before Git, before Mercurial, and the other DVCS, which means either you had SourceForge, or you likely had no source control at all. But SourceForge admins also reviewed (or at least alleged to) every project that was created, and so creating a project on the platform was not straightforward, you would do that only if you really had the time to invest on the project.

A few projects were big enough to have their own servers, and a few projects were hosted in some other “random” project management sites, that for a while appeared to sprout out because the Forge software used by SourceForge was (for a while at least) released as free software itself. Some of those websites were specific in nature, others more general. Over time, BerliOS appeared to become the anti-SourceForge, with a streamlined application process, and most importantly, with Subversion years before SF would gain support for it.

Things got a bit more interesting later, when things like Bazaar, Mercurial, GIT and so on started appearing on the horizon, because at that point having proper source control could be achieved without needing special servers (without publishing it at least, although there were ways around that. Which at the same time made some project management website redundant, and others more appealable.

But, let’s take a look at the list of project management websites I have used and are now completely or partly gone, with or without history:

  • The aforementioned BerliOS, which has been teetering back and forth a couple of times. I had a couple of projects over there, which I ended up importing to GitHub, and I also forked unpaper. The service and the hosting were taken down in 2014, but (all?) the projects hosted on the platform were mirrored on SourceForge. As far as I can tell they were mirrored read-only, so for instance I can’t de-duplicate the unieject projects since I originally wrote it on SourceForge and then migrated to BerliOS.

  • The Danish SunSITE, which hosted a number of open-source projects for reasons that I’m not entirely clear on. NoX-Wizard, an open-source Ultima OnLine server emulator was hosted there, for reasons that are even murkier to me. The site got renamed to dotsrc.org, but they dropped all the hosting services in 2009. I can’t seem to find an archive of their data; Nox-Wizard was migrated during my time to SourceForge, so that’s okay by me.

  • RubyForge used that same Forge app as SourceForge, and was focused on Ruby module development. It was abruptly terminated in 2014, and as it turns out I made the mistake here of not importing my few modules explicitly. I should have them in my backups if I start looking for them, I just haven’t done so yet.

  • Gitorious set itself up as being an open, free software software to compete with GitHub. Unfortunately it clearly was not profitable enough and it got acquired, twice. The second time by competing service GitLab, that had no interest in running the software. A brittle mirror of the project repositories only (no user pages) is still online, thanks to Archive Team. I originally used Gitorious for my repositories rather than GitHub, but I came around to it and moved everything over before they shut the service down, well almost everything, as it turns out some of the LScube repos were not saved, because they were only mirrors… except that the domain for that project expired so we lost access to the main website and GIT repository, too.

  • Google Code was Google’s project hosting service, that started by offering Subversion repositories, downloads, issue trackers and so on. Very few of the projects I tracked used Google Code to begin with, and it was finally turned down in 2015, by making all projects read-only except for setting up a redirection to a new homepage. The biggest project I followed from Google Code was libarchive and they migrated it fully to GitHub, including migrating the issues.

  • Gemcutter used to be a repository for Ruby gems packages. I actually forgot why it was started, but it was for a while the alternative repository where a lot of cool kids stored their libraries. Gemcutter got merged back into <a href="http://rubygems.org" rel="nofollow">rubygems.org</a> and the old links now appear to redirect to the right pages. Yay!

With such a list of project hosting websites going the way of the dodo, an obvious conclusion to take is that hosting things on your own servers is the way to go. I would still argue otherwise. Despite the amount of hosting websites going away, it feels to me like the vast majority of the information we lost over the past 13 years is for blogs and personal websites badly used for documentation. With the exception of RubyForge, all the above examples were properly archived one way or the other, so at least the majority of the historical memory is not gone at all.

Not using project hosting websites is obviously an option. Unfortunately it comes with the usual problems and with even higher risks of losing data. Even GitLab’s snafu had higher chances to be fixed than whatever your one-person-project has when the owner gets tired, runs out of money, graduate from university, or even dies.

So what can we do to make things more resilient to disappearing? Let me suggest a few points of actions, which I think are relevant and possible right now to make things better for everybody.

First of all, let’s all make sure that the Internet Archive by donating. I set up a €5/month donation which gets matched by my employer. The Archive not only provides the Wayback Machine, which is how I can still fetch some of the content both from my past blogs and from blogs of people who deleted or moved them, or even passed on. Internet is our history, we can’t let it disappear without effort.

Then for what concerns the projects themselves, it may be a bit less clear cut. The first thing I’ll be much more wary about in the future is relying on the support sites when writing comments or commit messages. Issue trackers get lost, or renumbered, and so the references to those may be broken too easily. Be verbose in your commit messages, and if needed provide a quoted issue, instead of just “Fix issue #1123”.

Even mailing lists are not safe. While Gmane is currently supposedly still online, most of the gmane links from my own blog are broken, and I need to find replacements for them.

This brings me to the following problem: documentation. Wikis made documenting things significantly cheaper as you don’t need o learn lots neither in form of syntax nor in form of process. Unfortunately, backing up wikis is not easy because a database is involved, and it’s very hard, when taking over a project whose maintainers are unresponsive, to find a good way to import the wiki. GitHub makes thing easier thanks to their GitHub pages, and it’s at least a starting point. Unfortunately it makes the process a little more messy than the wiki, but we can survive that, I’m sure.

Myself, I decided to use a hybrid approach. Given that some of my projects such as unieject managed to migrate from SourceForge to BerliOS, to Gitorious, to GitHub, I have now set up a number of redirects on my website, so that their official websites will read https://www.flameeyes.eu/p/glucometerutils and it’ll redirect to wherever I’m hosting them at the time.

Read the whole story
Flameeyes
13 hours ago
reply
Dublin, Ireland
Share this story
Delete

ELECOM DEFT and the broken descriptor

1 Share

In my previous post reviewing the ELECOM DEFT I noted that I had to do some work to get the three function buttons on the mouse to work on Linux correctly. Let me try to dig a bit into this one so it can be useful to others in the future.

The simptoms: the three top buttons (Fn1, Fn2, Fn3) of the device are unresponsive on Linux, they do not show up on xev and evtest.

My first guess was that they were using the same technique they do for gaming mice, by configuring on the device itself what codes to send when the buttons are pressed. That looked likely because the receiver is appearing as a big composite device. But that was not the case. After installing the Windows driver and app on my “sacrificial laptop”, and using USBlyzer to figure out what was going on, I couldn’t see the app doing anything to the device. Which meant they instead remapped the behaviour of the buttons on the software side.

This left open only the option that the receiver needs a “quirk driver” to do something. Actually, since I have looked into HID (the protocol used for USB mice and keyboards, among others), I already knew the problem was the HID Report Descriptor is reporting something broken and the Linux kernel is ignoring it. I’m not sure if Windows is just ignoring the descriptor, or if there is a custom driver to implement the quirk there. I did not look too much into this.

But what is this descriptor? If you have not looked into HID before, you have to understand that the HID protocol in USB only specifies very little information by itself, and is mainly a common format for both sending “reports” and to describe said reports. The HID Report Descriptor is effectively bytecode representing the schema that those reports should follow. As it happens, sometimes it’s not the case at all, and the descriptor itself can even be completely broken and unparsable. But that is not the case here.

The descriptor is fetched by the operating system when you connect the device, and is then used to parse the reports coming as interrupt transfer. The first byte of each transfer refers to the report used, and that is looked up in the descriptor to understand it. In most mice, your reports will all look vastly the same: state of the buttons, relative X and Y displacement, wheel (one or two dimensional) displacement. But, since the presence of one or more wheels is not a given, and the amount of buttons to expect can be significantly high, even without going to the ludicrous extent of the OpenOffice mouse, the report descriptor will tell you the size of each field in the structure.

So, looking at USBlyzer, I could tell that the report number 1 was clearly the one that gives the mouse data, and even without knowing much about HID and having not seen the report descriptor, I can tell what’s going on:

button1: 01 01 00 00 00 00 00 00
button2: 01 02 00 00 00 00 00 00
button3: 01 04 00 00 00 00 00 00
fn1:     01 20 00 00 00 00 00 00
fn2:     01 40 00 00 00 00 00 00
fn3:     01 80 00 00 00 00 00 00

So quite obviously, the second byte is a bitmask of which button is being pressed. Note that this is the first of two reports you receive every time you click on the button (and everything is zero because on a trackball you can click the buttons without even touching the ball, and so there is no movement indication in the report).

But, when I looked at the Analysis tab, I found out that USBlyzer is going to parse the reports based on the descriptor as well, showing the button number from the bitmask, the X and Y displacement and so on. For the bitmasks of the three buttons at the top of the device, no button is listed in the analysis. Bingo, we have a problem.

The quest items. Thinking of it like a quest in a JRPG, I now needed two items to complete the quest: a way to figure out what the report descriptor of the device is and what it means. Let’s start from the first item.

There are a number of ways that you find documented for dumping a USB HID report descriptor on Linux. Most of them rely on you unbinding the device from the usbhid driver and then fetching it by sending the right HID commands. usbhid-dump does that and it does well, but I’m going to ignore that. Instead I’m going to read the report descriptor as is presented by sysfs. This may not be the one reported by the hardware, but rather the one that the quirk may have already “fixed” somehow.

So how can you tell where to find the report descriptor? If you look when you plug in a device:

% dmesg | tail -n 3
[13358.058915] elecom 0003:056E:00FF.000C: Fixing up Elecom DEFT Fn buttons
[13358.059721] input: ELECOM ELECOM TrackBall Mouse as /devices/pci0000:00/0000:00:14.0/usb3/3-2/3-2.1/3-2.1:1.0/0003:056E:00FF.000C/input/input45
[13358.111673] elecom 0003:056E:00FF.000C: input,hiddev0,hidraw1: USB HID v1.11 Mouse [ELECOM ELECOM TrackBall Mouse] on usb-0000:00:14.0-2.1/input0
% cp /sys/devices/pci0000:00/0000:00:14.0/usb3/3-2/3-2.1/3-2.1:1.0/0003:056E:00FF.000C/report_descriptor my_report_descriptor.bin

You can tell from this dmesg that I’m cheating, and I’m looking at it after the device has been fixed already. Otherwise it would probably be saying hid-generic rather than elecom.

I have made a copy of the original report descriptor of course, so I can look at it even now, but the binary file is not going to be very useful by itself. But, from the same author as the tool listed above, hidrd makes it significantly easier to understand what’s going on. The full spec output includes a number of report pages that are vendor specific, and may be interesting to either fuzz or figure out if they are used for reporting things such as low battery. But let’s ignore that for the immediate and let’s look at the “Desktop, Mouse” page:

Usage Page (Desktop),               ; Generic desktop controls (01h)
Usage (Mouse),                      ; Mouse (02h, application collection)
Collection (Application),
    Usage (Pointer),                ; Pointer (01h, physical collection)
    Collection (Physical),
        Report ID (1),
        Report Count (5),
        Report Size (1),
        Usage Page (Button),        ; Button (09h)
        Usage Minimum (01h),
        Usage Maximum (05h),
        Logical Minimum (0),
        Logical Maximum (1),
        Input (Variable),
        Report Count (1),
        Report Size (3),
        Input (Constant),
        Report Size (16),
        Report Count (2),
        Usage Page (Desktop),       ; Generic desktop controls (01h)
        Usage (X),                  ; X (30h, dynamic value)
        Usage (Y),                  ; Y (31h, dynamic value)
        Logical Minimum (-32768),
        Logical Maximum (32767),
        Input (Variable, Relative),
    End Collection,
    Collection (Physical),
        Report Count (1),
        Report Size (8),
        Usage Page (Desktop),       ; Generic desktop controls (01h)
        Usage (Wheel),              ; Wheel (38h, dynamic value)
        Logical Minimum (-127),
        Logical Maximum (127),
        Input (Variable, Relative),
    End Collection,
    Collection (Physical),
        Report Count (1),
        Report Size (8),
        Usage Page (Consumer),      ; Consumer (0Ch)
        Usage (AC Pan),             ; AC pan (0238h, linear control)
        Logical Minimum (-127),
        Logical Maximum (127),
        Input (Variable, Relative),
    End Collection,
End Collection,

This is effectively a description of the structure in the reported I showed earlier, starting from the buttons and X/Y displacement, followed by the wheel and the “AC pan” (which I assume is the left/right wheel). All the sizes are given in bits, and the way the language works is a bit strange. The part that interests us is at the start of the first block. Refer to this tutorial for the nitty gritty details, but I’ll try to give a human-readable example.

Report ID is the constant we already know about, and the first byte of the message. Following that we can see it declaring five (Count = 5) bits (Size = 1) used for Buttons between 1 and 5. Ignore the local maximum/minimum in this case, as they are of course either on or off. The Input (Variable) instruction is effectively saying “These are the useful parts”. Following that it declares one (Count = 1) 3-bit (Size = 3) constant value. Since it’s constant, the HID driver will just ignore it. Unfortunately those three bits are actually the three bits needed for the top buttons.

The obvious answer is to change the descriptor so that it describe eight one-bit entries for eight buttons, and no constant bits (if you forget to remove the constant bits, the whole message gets misparsed and moving the mouse is taken as clicks, ask me how I know!). How do you do that? Well, you need a quirk driver in the Linux kernel to intercept the device, and rewrite the descriptor on the fly. This is not hard, and I know of plenty of other drivers doing so. As it happens Linux already has a hid-elecom driver, which was fixing a Bluetooth mouse that also had a wrong descriptor; I extended that to fix the descriptor. But how do you fix a descriptor exactly?

Some of the drivers check for the size of the descriptor, and for some anchor values (usually the ones they are going to change), others replace the descriptor entirely. I prefer the former, as they make it clear that they are trying to just fix something rather than discard whatever the manufacturer is doing. Particularly because in this case the fix is quite trivial, just three bytes need to be changed: change the Count and Maximum for the Buttons input to 8, and make the Count of the constant import zero. hidrd has a mode where it outputs the whole descriptor as a valid C array that you can just embed in the kernel source, with comments what each byte combination does. I used that during testing, before changing my code to do the patching instead. The actual diff, in code format, is:

@@ -4,15 +4,15 @@
 0x09, 0x01,         /*      Usage (Pointer),                */
 0xA1, 0x00,         /*      Collection (Physical),          */
 0x85, 0x01,         /*          Report ID (1),              */
-0x95, 0x05,         /*          Report Count (5),           */
+0x95, 0x08,         /*          Report Count (8),           */
 0x75, 0x01,         /*          Report Size (1),            */
 0x05, 0x09,         /*          Usage Page (Button),        */
 0x19, 0x01,         /*          Usage Minimum (01h),        */
-0x29, 0x05,         /*          Usage Maximum (05h),        */
+0x29, 0x08,         /*          Usage Maximum (08h),        */
 0x15, 0x00,         /*          Logical Minimum (0),        */
 0x25, 0x01,         /*          Logical Maximum (1),        */
 0x81, 0x02,         /*          Input (Variable),           */
-0x95, 0x01,         /*          Report Count (1),           */
+0x95, 0x00,         /*          Report Count (0),           */
 0x75, 0x03,         /*          Report Size (3),            */
 0x81, 0x01,         /*          Input (Constant),           */
 0x75, 0x10,         /*          Report Size (16),           */

And that’s enough to make all the buttons work just fine. Yay! So I sent the first patch to the linux-input mailing list… and then I had a doubt “Am I the first ever Linux user of this device?” As it happens, I’m not, and after sending the patch I searched and found that there was already a patch by Yuxuan Shui sent last year that does effectively the same thing, except with a new module altogether (rather than extending the one already there) and by removing the Constant input declaration altogether, which requires a memmove() of the rest of the input. It also contains the USB ID for the wired version of the DEFT, adding the same fix.

So I went and sent another (or three) revision of the patch, including the other ID. Of course I would argue that mine is cleaner by reusing the other module, but in general I’ll leave it to the maintainers to decide which one to use. One thing that I can say at least for mine is that I tried to make it very explicit what’s going on, in particular by adding as a comment the side-by-side diff of the Collection stanza that I change in the driver. Because I always find it bothersome when I have to look into one of those HID drivers and they seem to just come up with magical constants to save the day. Sigh!

Read the whole story
Flameeyes
4 days ago
reply
Dublin, Ireland
Share this story
Delete

Hardware Review: ELECOM DEFT Trackball

1 Share

I know that by this point it feels like I’m collecting half-done reverse engineering projects, but sometimes you need some time off from one project to figure out how another is going to behave, so I have temporarily shelved my Accu-Chek Mobile and instead took a day to look at a different problem altogether.

I like trackballs, and with exception of gaming purposes, I consider them superior to mice: no cables that get tangled, no hands to move around the desk, much less space needed to keep clear, and so on. On laptops I prefer TrackPoint™ Style Pointers, which are rare to find, but on desktop I am a happy user of trackballs. Unfortunately my happiness has been having trouble as of late, because finding good trackballs is getting harder. My favourite device would still be Logitech’s Cordless Optical Trackman, but it was discontinued years ago, and it’s effectively impossible to find to buy. Amazon has second-hand listings for hundreds of dollars! I’m still kicking myself in the face for having dropped mine on the floor (literally) while I packed to move to Dublin, completely destroying it.

The new Logitech offerings appear to be all in the realm of thumb-operated “portable” trackballs, such as the M570, which I have and don’t particularly like. An alternative manufacturer that is easy to find both online and in store is Kensington, and I do indeed own an Orbit with the scroll ring, but it’s in my opinion too avant-garde and inconvenient. So I have been mostly unhappy.

But last year a colleague, also a trackball user, suggested me to look into the ELECOM DEFT Trackball (also available wired).

ELECOM, for those who may not be familiar with it, is a Japanese hardware company, that would sell everything from input devices to ultra flat network cables. If you have not been to Japan, it may be interesting to know that there is effectively a parallel world of hardware devices that you would not find in Europe or the USA, which makes a visit to Yodobashi Camera a must-see for every self-respecting geek.

I got the DEFT last year, and loved it. I’ve been using it at work all the time, because that’s where I mostly use a non-gaming input device anyway, but recently I started working from home a bit more often (it’s a long story) and got myself a proper setup for it, with a monitor, keyboard and, for a while, the M570 I noted above. I decided then to get myself two more of the DEFT, one to use with my work from home setup, and the other to use with my personal laptop while I work on reverse engineering.

Note here: I made a huge mistake. In both cases I ordered them from eBay directly from Japan, so I had to deal with the boring customs and VAT modules on my end. Which is not terrible, since the An Post depot is about ten minutes away from my apartment and my office, but it’s still less nice than just receiving the package directly. The second order, I ended up receiving two “Certified Frustration Free” packages, so I checked and indeed these devices are available on Amazon Japan. As I found out a few weeks ago for a completely different product, there is a feature called AmazonGlobal, which is not available for all products but would have been for these. With AmazonGlobal, the customs and VAT charges are taken care by Amazon, so there is no need for me to go out of my way and pay cash to An Post. And as it happens, if you don’t want to sign up for an account with Amazon Japan (which somehow is not federated to the others), you can just look for the same product on the USA version of Amazon, and AmazonGlobal applies just the same.

The trackball has a forefinger-operated ball (although ELECOM also makes a thumb-operated trackball), the usual left/middle/right buttons, a scroll wheel that “tilts” (badly) horizontally, and three function buttons at the top of the mouse (which I’ll go back to later). It also has two switches, one on the side, that has a red or blue area showing depending on how you pull it, and one on the bottom that is marked with the power symbol, H and L. Unfortunately, the manual leaflet that comes with the device is all in Japanese, which meant I had to get the help of Google Translate with my phone’s camera.

The switch on the side selects the DPI of the ball tracking (750 for blue, 1500 for red), while the one at the bottom appear to be a “power-assist” for the ball — it warns that the H version will use more battery.

As I said before, the trackball has three function buttons (marked Fn1, Fn2, Fn3) on the top. These are, for what I could tell, configurable through the Windows and Mac application, and they were indeed not seen by Linux at all, neither through xev nor through evtest. So I set myself up to reverse whichever protocol they used to configure this — I expected something similar to the Anker/Holtek gaming mouse I’m also working on, where the software programs the special event ID in the device directly.

The software can be downloaded on ELECOM’s website, although the whole page is in Japanese. On the other hand, the software itself is (badly) translated to English, so fewer yaks to shave there. Unfortunately when I tried using the app with the USB sniffer open… I could find nothing whatsoever. Turns out the app is actually handling all of that in software, rather than programming the hardware. So why did it not work on Linux? Well, I think that may be the topic for another post, since it turned out to require a kernel patch (which I sent, but can’t currently quite find it in the archives. I think that writing a blog post about it is going to be fairly useful, given that I had to assemble documentation that I found on at least a half dozen different sites.

Other things that may be relevant to know about the ELECOM is that somehow the 2.4GHz connection is sometimes a bit unstable. At the office, I cannot connect the receiver on the USB behind the monitor, because otherwise it skips beats. At home instead I have to put it there, because if I try to connect it directly to the Anker USB-C adapter I use with my Chromebook, the same problem happens. Ironically, the Microsoft receiver has the opposite problem: if I connect it behind the monitor at home, the keyboard sometimes get stuck repeating the same key over and over again. But again, that’s a topic for another time.

Read the whole story
Flameeyes
7 days ago
reply
Dublin, Ireland
Share this story
Delete

IHG Payment Card Breach Affecting 1,175 Hotels In The United States

1 Share

IHG seems to have had quite a serious payment card breach that has affected 1,175 franchised hotels in the United States.

IHG United States Breach April 2017

There has been quite a few breaches at hotels over the past few years but they have always affected POS (Point-Of Sale) terminals at hotels where customers settled their bills. This time, however, the malware has effaced front desk computers by capturing their swipe date.

You can access IHG’s web page for this breach here.

READ MORE: IHG Rewards Club Rate & Bonus Points And Miles Promotions

The breach started on September 29, 2016, and should have been eradicated by end of March 2017.

Here’s the list of 1,175 affected hotels:

Download (PDF, 409KB)

Here’s the press release from IHG:

ATLANTA, April 14, 2017 /PRNewswire/ — IHG values the relationship it has with its guests and understands the importance of protecting payment card data.  Many IHG-branded locations are independently owned and operated franchises, and certain of these franchisee operated locations in the Americas were made aware by payment card networks of patterns of unauthorized charges occurring on payment cards after they were legitimately used at their locations.  To ensure an efficient and effective response, IHG hired a leading cyber security firm on behalf of franchisees to coordinate an examination of the payment card processing systems of franchise hotel locations in the Americas region.

The investigation identified signs of the operation of malware designed to access payment card data from cards used onsite at the front desk at certain IHG-branded franchise hotel locations between September 29, 2016 and December 29, 2016.  Although there is no evidence of unauthorized access to payment card data after December 29, 2016, confirmation that the malware was eradicated did not occur until the properties were investigated in February and March 2017.  Before this incident began, many IHG-branded franchise hotel locations had implemented IHG’s Secure Payment Solution (SPS), a point-to-point encryption payment acceptance solution.  Properties that had implemented SPS before September 29, 2016 were not affected.  Many more properties implemented SPS after September 29, 2016, and the implementation of SPS ended the ability of the malware to find payment card data and, therefore, cards used at these locations after SPS implementation were not affected.  

The malware searched for track data (which sometimes has cardholder name in addition to card number, expiration date, and internal verification code) read from the magnetic stripe of a payment card as it was being routed through the affected hotel server. There is no indication that other guest information was affected.  A list of affected franchise locations and respective time frames, which may vary by location, is available at www.ihg.com/protectingourguests. The site also contains more information on steps guests may take.    

It is always advisable to remain vigilant to the possibility of fraud by reviewing your payment card statements for any unauthorized activity. You should immediately report any unauthorized charges to your card issuer because payment card rules generally provide that cardholders are not responsible for unauthorized charges reported in a timely manner.  The phone number to call is usually on the back of your payment card.  

On behalf of franchisees, IHG has been working closely with the payment card networks as well as with the cyber security firm to confirm that the malware has been eradicated and evaluate ways for franchisees to enhance security measures.  Law enforcement has also been notified. IHG also has established a dedicated call center to answer any questions affected guests may have. 

Conclusion

Not sure why IHG uses the word Americas when describing this breach when all the hotels affected are in the United States?

This is getting very serious. As I wrote above, the previous incidents hadn’t infected the computers and terminals used at the front desk but those at restaurants and shops within hotels.  It is interesting that IHG is referring this to as an “incident” to minimize the public perception of the gravity of the breach. There also seems to be an attempt to distance themselves from the properties by continually making mention of the properties being franchises. 

I am surprised that IHG is not offering free credit monitoring to those affected guests that stayed at these hotels during the potential breach period. IHG only advises guests to use the yearly free credit report to monitor their files.

Read the whole story
Flameeyes
11 days ago
reply
Dublin, Ireland
Share this story
Delete

Why don't you just rewrite it in X?

1 Share

Why don't you just rewrite it in X?



Whenever a new programming language becomes popular its fanpersons start evangelizing its virtues by going to existing projects and filing bug reports that look like this. Hi, I noticed that this project is written in [programming language X].

Tags:

via Pocket <a href="http://nibblestew.blogspot.com/2017/04/why-dont-you-just-rewrite-it-in-x.html" rel="nofollow">http://nibblestew.blogspot.com/2017/04/why-dont-you-just-rewrite-it-in-x.html</a>

April 17, 2017 at 06:44PM

Read the whole story
Flameeyes
11 days ago
reply
Dublin, Ireland
Share this story
Delete

Overbooking – What Is That And How Do Airlines Typically Solve The Problem (Without Violence)?

1 Share

In the past couple of days one term has gotten plenty of attention due to United’s very unconventional handling of such a situation: ‘Overbooking’ of flights.

We want to shine a little light on what overbooking actually means, who makes use of it and what is the typical way of dealing with customers in such a situation.

Despite many stories written about the circumstances surrounding the United Airlines flight where a paying passenger got dragged out of the plane by security and injured in the process, overbooking of scheduled services are a common occurrence in the airline industry and usually solved in an amicable way.

What is overbooking?

‘Overbooking’ [or Overselling] is a term that describes the practice of selling more inventory than a company has available, taking into account a projection of cancellations and no-shows for a certain product or service. This projection is commonly known as yield management and run by an algorithm, taking past experience values into account.

Example 1: A flight from Los Angeles to Chicago has 250 seats but it is estimated that until the day of departure 25 of these reservations will either get cancelled or passengers won’t show up for their flight. The airline therefore sells 275 seats, hoping they break even at the time of departure.

Example 2: A hotel has 500 Rooms and based on experience of last minute cancellations (especially of flexible rates and by corporate customers) they continue to sell beyond actual capacity until a few days before to make sure they don’t lose out in revenue.

Who overbooks?

Industries throughout the hospitality business constantly engage in overselling of their inventory. This includes airlines, hotels, rental car companies and bus tours.

What happens if overbooking isn’t breaking even as anticipated?

Every now and then there are actually more customers than available seats on an aircraft, rooms at hotels or cars at a rental car agency and then the company has a problem. They will have to explain the situation to the customer and in the worst case deny them the service as reserved in which case the customer is entitled to compensation and in many cases a refund of his purchase.

To avoid denying the customer a service outright at the last minute, companies often approach clients ahead of time throughout the day and offer them (in most cases) lucrative compensation if they voluntarily agree to surrender their reservation and agree to travel another day or using the service of a competitor with all expenses paid. Such compensation is typically issued in vouchers for the respective company good towards a future purchase but in some cases also includes cash compensation, especially where required by law such in the European Union based on Air Passenger rights per EC261/2004.

What type of compensation if typically offered?

The type of compensation offered can vary greatly based on the provider and the urgency of the situation. When it comes to an oversold flight the jurisdiction where the matter occurs is also important.

Here are a few offers I personally received in the previous 2 years on various routes for voluntary denied boarding, also known as ‘Taking a bump’ (giving up your seat):

  1. Delta Airlines Los Angeles to Detroit, flight oversold and the airline offered $800 in travel vouchers to fly 2 hours later (I accepted).
  2. Delta Airlines Los Angeles to Tokyo, flight oversold and Delta offered $1,200 in travel vouchers plus hotels and meals to travel the following day (I accepted).
  3. United Airlines Las Vegas to Los Angeles, flight oversold and got offered $300 in travel certificates to fly 4 hours later (I declined).
  4. American Airlines San Jose, CA to Los Angeles, flight oversold and American offered $600 travel vouchers to fly 5 hours later. I accepted but wasn’t needed as a volunteer in the last minute.
  5. Lufthansa Frankfurt to Vancouver, flight oversold and was offered a voucher good for 600 EUR cash to travel either the following day or on Air Canada via Calgary. I accepted, chose the Air Canada option and got the cash when presenting the voucher at the Ticket Counter.

What are my legal rights?

When purchasing a ticket you enter into a contract of carriage (COC) with the airline that has tons of fine print that 99% of the passengers will never read in their life. Nevertheless and regardless whats written in that COC, it can not trump federal law and regulations governing air travel in the respective jurisdiction. Airlines are therefore required to comply with the legislation in terms of passenger rights and compensation as applicable based on the situation.

Here are two legal provision, one for passengers in the United States based on U.S. Law and the other for passengers whose flights fall under the jurisdiction of the European Union.

This is the U.S. legislation:

14 CFR 250.5 – Amount of denied boarding compensation for passengers denied boarding involuntarily.

(a) Subject to the exceptions provided in § 250.6, a carrier to whom this part applies as described in § 250.2 shall pay compensation in interstate air transportation to passengers who are denied boarding involuntarily from an oversold flight as follows:

(1) No compensation is required if the carrier offers alternate transportation that, at the time the arrangement is made, is planned to arrive at the airport of the passenger’s first stopover, or if none, the airport of the passenger’s final destination not later than one hour after the planned arrival time of the passenger’s original flight;

(2) Compensation shall be 200% of the fare to the passenger’s destination or first stopover, with a maximum of $675, if the carrier offers alternate transportation that, at the time the arrangement is made, is planned to arrive at the airport of the passenger’s first stopover, or if none, the airport of the passenger’s final destination more than one hour but less than two hours after the planned arrival time of the passenger’s original flight; and

(3) Compensation shall be 400% of the fare to the passenger’s destination or first stopover, with a maximum of $1,350, if the carrier does not offer alternate transportation that, at the time the arrangement is made, is planned to arrive at the airport of the passenger’s first stopover, or if none, the airport of the passenger’s final destination less than two hours after the planned arrival time of the passenger’s original flight.

(b) Subject to the exceptions provided in § 250.6, a carrier to whom this part applies as described in § 250.2 shall pay compensation to passengers in foreign air transportation who are denied boarding involuntarily at a U.S. airport from an oversold flight as follows:

(1) No compensation is required if the carrier offers alternate transportation that, at the time the arrangement is made, is planned to arrive at the airport of the passenger’s first stopover, or if not, the airport of the passenger’s final destination not later than one hour after the planned arrival time of the passenger’s original flight;

(2) Compensation shall be 200% of the fare to the passenger’s destination or first stopover, with a maximum of $675, if the carrier offers alternate transportation that, at the time the arrangement is made, is planned to arrive at the airport of the passenger’s first stopover, or if not, the airport of the passenger’s final destination more than one hour but less than four hours after the planned arrival time of the passenger’s original flight; and

(3) Compensation shall be 400% of the fare to the passenger’s destination or first stopover, with a maximum of $1,350, if the carrier does not offer alternate transportation that, at the time the arrangement is made, is planned to arrive at the airport of the passenger’s first stopover, or if not, the airport of the passenger’s final destination less than four hours after the planned arrival time of the passenger’s original flight.

(c) Carriers may offer free or reduced rate air transportation in lieu of the cash or check due under paragraphs (a) and (b) of this section, if –

(1) The value of the transportation benefit offered, excluding any fees or other mandatory charges applicable for using the free or reduced rate air transportation, is equal to or greater than the cash/check payment otherwise required;

(2) The carrier fully informs the passenger of the amount of cash/check compensation that would otherwise be due and that the passenger may decline the transportation benefit and receive the cash/check payment; and

(3) The carrier fully discloses all material restrictions, including but not limited to, administrative fees, advance purchase or capacity restrictions, and blackout dates applicable to the offer, on the use of such free or reduced rate transportation before the passenger decides to give up the cash/check payment in exchange for such transportation. (See also § 250.9(c)).

This applies to involuntary denied boarding situations and therefore places a cash burden on the carrier to better find volunteers willing to give up their seats in lieu for vouchers rather than cash. Voluntary denied boardings are subject to whatever the parties agree to while passengers in involuntary scenarios are always entitled to cash payments within the framework above, especially when no timely alternative is offered.

The case is different in the European Union and those countries that adopted the EC261/2004 such as Switzerland and Iceland as can be seen by the passenger rights provided by Lufthansa (see here).

Denied Boarding

If in case of overbooking you are denied boarding involuntarily on a flight for which you hold a reservation, you are entitled to care and compensation without delay and to a refund as laid out in the previous section on ’delay’. In addition you are entitled to re-routing, under comparable conditions, to your final destination at the earliest opportunity.

Subject to availability of seats, you may instead choose re-routing to your final destination at a later date of your convenience, in which case you will have to bear yourself the cost of food, accommodation and transfer.

If you are involuntarily or voluntarily denied boarding, you have the right to an alternative flight or to a refund and compensation which can also be paid as a cheque, by bank transfer or, with your agreement, in the form of a voucher.

The compensation shall be paid in cash, cheque or transfer or with your agreement in form of vouchers. The amount of the compensation depends on the distance of the schedule flight or the alternative flight proposed to you. Compensations amount to:

  • 250 € for flights up to 1.500 km
  • 400 € for flights between 1.500 km and 3.500 and intra-Community flights of more than 1.500 km,
  • 600 € for flights of more then 3.500

If you are offered an alternative flight, the scheduled arrival time of which does not exceed 2 hours in respect of flights up to 1.500 km, 3 hours in respect of flights between 1.500k m and 3.500 km as well as intra-Community flights of more than 1.500 km, and 4 hours in respect of all other flights, the above, mentioned compensation amounts can be reduced by 50%, i.e.125 €, 200 € and 300 €.

These rights are not granted if you have been denied boarding on reasonable grounds, such as reasons of health, general or operational security, or inadequate travel documentation.

The EU regulation generally covers passengers with a blanket cash entitlement for many scenarios including denied boarding and delay situations. I myself have claimed EU compensation many times successfully. Sometimes it requires a bit of a push, the involvement of an ombudsman a regulator complaint or even an attorney but well founded cased will usually yield in full compensation being paid.

Conclusion

I don’t want to chew around on the United incident any longer which was more than unfortunate and will cost the company a pretty penny in both compensation, image, market capital and PR damage control.

What’s more important is that passengers know their rights and even if the airline undermines their passenger rights at the very given moment to take them on later in court and through a complaint to the Department of Transportation. It rarely serves anyone to start a fight with these people, better collect your cash award in the end.

I said it before when writing about a previous case involving a downgrade on British Airways that airlines and their personnel often prey on weak passengers such as foreigners with little language capability, elderly, youths and anyone who doesn’t really know how to defend themselves in such a scenario to get them downgraded or bumped off a flight with very little argument.

Read the whole story
Flameeyes
16 days ago
reply
Dublin, Ireland
Share this story
Delete
Next Page of Stories