Thursday, October 1, 2015

Evolution or e-volution?

Evolution or e-volution?

Shortly after the World Trade Center 9/11 disaster in New York City, I found myself reflecting on friendships and people I have lost along the way.

I turned inside myself and began journaling on a daily basis to help myself overcome the horror and isolation that comes with such an event.

Friends I had gone to school with; productive members of the community... people who had accomplished so many things I had yet to do myself. So different from the I was living at the time.

The feelings were overwhelming and went far beyond fear, solitude, and I began to question my purpose in this life.

Had I been just a few miles closer, heading west that day instead of east, I would have driven right into Ground Zero.

Friends circulated e-mails about form,er classmates that were presumed dead. They had families: pregnant wives, children, and all of the things that I believed I would have by the time I reached my 30's.

I quickly realized how many of my peers had achieved at least some of the goals they set out to accomplish years earlier— and I felt pangs of guilt and sadness seeing how much they were loved, how fondly they were remembered, and how many of them were on their way to achieving great things.

By that time, I was nearing my thirtieth birthday and the list of goals I set for myself seemed hopelessly beyond my reach.

Not just beyond my grasp— the future seemed ominous, scary, and it took everything I had to keep myself alive.

In the months after the assault, I became increasingly aware of just how disconnected I was from my past.

Before FaceBook, there was classmates.com…. One day I got one of those e-mails that makes you feel as though someone from my past was trying to contact me. I thought long and hard before I responded.

I had a mix of emotions.

I had done everything I possibly could to quietly erase any ties or connections I had to the past.

Filling out the online registration for FaceBook; responding to my 20th reunion invitations; afraid to be exposed for being poor.... but then it came time....

I am not poor, I am merely a rich person without any money.

Because I had never lived with one parent, one house, or one school any longer than a year or two at best, it was not that hard to fade away into a distant memory.

I wanted to be forgotten.

The last few weeks of my life have been anything short of living moment to moment... confronted with all the crises I wanted so badly to leave behind.... yet those experiences; my fight or flight instinct carried me through.

Thank you to all who tweeted and chatted... I made it through the storm, and I am glad to know you were there with me.

I am glad to be alive today, and I look forward to attending at least one of the three possible reunions. I hope you are glad to have me.

Cheers to you all, can't wait to see y'all at the Freak Parade!


Just me,

e




DailyDDoSe

Telecommunications Access Disability Compliance under FCC Section 255 including VOIP

Telecommunications Access Disability Compliance under FCC Section 255 including VOIP

The FCC has rules requiring telecommunications equipment manufacturers and service providers to make their products and services accessible to people with disabilities, if such access is readily achievable. These rules implement Section 255 of the Communications Act. Where access is not readily achievable, Section 255 requires manufacturers and service providers to make their devices and services compatible with peripheral devices and specialized customer premises equipment that are commonly used by people with disabilities, if such compatibility is readily achievable.

The FCC has determined that interconnected Voice over Internet Protocol (VoIP) providers must comply with Section 255.

Products and Services Covered Under Section 255

The FCC's rules cover all hardware and software telephone network equipment and customer premises equipment (CPE). CPE is telecommunications equipment used in the home or office (or other premises) to originate, route or terminate telecommunications.

Examples of CPE are telephones, wireless handsets, fax machines, answering machines and pagers. CPE that provides both telecommunications and non-telecommunications functions is covered under Section 255 only to the extent it provides telecommunications functions.

The FCC's rules cover basic and special telecommunications services, including regular telephone calls, call waiting, speed dialing, call forwarding, computer-provided directory assistance, call monitoring, caller identification, call tracing and repeat dialing. In addition, the rules cover interactive voice response (IVR) systems and voice mail. IVR systems are phone systems that provide callers with menus of choices.

Definitions

Accessible: A product or service is deemed accessible if it provides accessible input, control and mechanical functions, as well as accessible output, display and control functions. For example, a pager that has both audio and visual controls for inputting information, as well as both audio and visual methods for retrieving messages, would be accessible to a person who is blind or deaf.

Usable: For a product or service to be usable, people with disabilities must be able to learn about and operate the product's or service's features effectively. This requirement includes providing access to information and documentation for the product or service, including instructions and user guides. In addition, companies must provide functionally equivalent access to support services, such as technical support hotlines and databases, call centers, service centers, repair services and billing services.

Compatible: The FCC requires that, where accessibility is not readily achievable, a product or service must be made compatible with peripheral devices or specialized customer premises equipment (SCPE), if compatibility is readily achievable. Peripheral devices are devices that help make telecommunications products and services accessible to individuals with disabilities.

Examples are teletypewriters (TTYs), visual signaling devices and amplifiers. SCPE includes equipment, commonly used at the premises of a person with a disability, to achieve access in the origination, routing or termination of calls and other telecommunications contacts. Direct-connect TTYs (TTYs that connect directly to the telephone network) are considered to be SCPE. Assistive technology devices, such as hearing aids or eyeglasses, that have a broad application outside the telecommunications context, are not themselves peripheral equipment or SCPE, even if they are used in conjunction with peripheral equipment or SCPE. To achieve compatibility, the FCC rules require:

external electronic access to all information and control mechanisms;
a connection point for external audio processing devices;
the ability to connect with TTYs; and
the ability to use TTY signals.

Identifying Access Needs

Companies should engage in a number of activities to identify barriers to accessibility and usability.

For example:

When conducting market research, product design, testing, pilot demonstrations and product trials, companies should include individuals with disabilities in target groups for such activities;

Companies should work cooperatively with disability-related organizations; and
Companies should undertake reasonable efforts to test access solutions with people with disabilities.

When Must Manufacturers and Service Providers

Evaluate Access Needs?

Manufacturers and service providers must evaluate the accessibility, usability and compatibility of their equipment and services as early and consistently as possible throughout their design, development and manufacture. In addition, companies must review their products for accessibility at every "natural opportunity," including when they re-design products, upgrade services, or significantly change the way they group together product and service packages.

Cosmetic changes that do not change the product's actual design, such as changes in the color, make, model name or designation of a product, may not trigger the need to reevaluate access.

Do Companies Need to Review All of Their Products and Services for Accessibility and Usability?

Yes. Accessibility and usability must be assessed for individual products and services. Accessibility features that can be incorporated into the design of products or services with very little or no difficulty or expense must be put in each and every product or service. When it is not readily achievable to incorporate accessibility features into every product or service, companies may distribute access features across product or service lines, so long as the companies implement all features that are readily achievable.

How Will the FCC Determine Which Actions Are Readily Achievable?

The "readily achievable" standard requires companies to incorporate access features that are easily accomplishable without much difficulty or expense. In determining what is readily achievable, companies must balance the costs and nature of the access required with their available resources. Companies that have great resources will need to do more to achieve access than companies with smaller budgets.

The FCC will make readily achievable determinations on a case-by-case basis. A company may not need to provide access when the access feature would so fundamentally alter the product that it would substantially reduce the functionality of the product, make some features unusable, substantially impede or deter use of the product by other individuals, or substantially and materially alter the shape, size or weight of the product. Similarly, a company is not obligated to incorporate an access feature that is not technically possible. Companies wishing to use these defenses, however, must provide evidence to back up their positions.

Is Network Architecture Covered by the FCC's Section 255 Rules?

In addition to covering equipment and services, the FCC's rules require network architecture to be designed in a way that does not hinder access by people with disabilities. Network architecture covers the public switched telephone network, and includes hardware or software databases associated with routing telecommunications services.

How Can I Contact Manufacturers and Service Providers About Access Concerns?

Although not required to do so, you may want to contact a manufacturer or service provider before filing a complaint with the FCC. Telecommunications service providers and equipment manufacturers must provide the FCC with the name and contact information of the person (or persons) in their companies who are authorized to resolve accessibility complaints. The FCC makes this information available to consumers who want to contact the company's customer care representative directly about accessibility questions, concerns, or complaints. You can find this contact information on the FCC's website, by sending an email to dro@fcc.gov, or by calling 202-418-2517 (voice) or 202-418-2922 (TTY).

Filing a Complaint with the FCC

To implement the Twenty-First Century Communications and Video Accessibility Act of 2010 (CVAA), the FCC changed the way it handles complaints about access to telecommunications services and equipment.

Before an informal complaint can be filed, consumers with disabilities (or their representatives) must request assistance from the FCC Disability Rights Office. The Disability Rights Office will work with the consumer and the company for at least 30 days to try to resolve the accessibility problem. There is no charge for this assistance.

The best way to provide the information that the Disability Rights Office needs to assist you, is to complete the Request for Dispute Assistance (RDA Form) online. You may also download or print the RDA Form. If you use the latter method, complete and submit your downloaded/printed request and any supporting documentation to the Disability Rights Office by email to dro@fcc.gov, by fax to 202-418-0037, or by mail to:

Federal Communications Commission
Consumer and Governmental Affairs Bureau
Disability Rights Office
445 12th Street, SW
Washington, D.C. 20554

If you are unable to obtain or use an RDA Form, your request for assistance should include the following:

your contact information
your name, address, telephone number, and email address
if communication by telephone or email is not accessible to you, your preferred method of communication
information about your accessibility problem
the name of the manufacturer or service provider
the type of device, model number, and any software involved
when you purchased, acquired, or used (or tried to purchase, acquire, or use) the service or equipment
when you became aware of the accessibility problem
the way the service or equipment is not accessible to or usable by you
if you contacted the company about your accessibility problem, how the company responded
what you want the company to do to resolve your accessibility problem
any other information or documentation you think may help describe or resolve your accessibility problem


Your Request for Dispute Assistance will be assigned a case number. If your accessibility problem is not resolved in 30 days, you have two choices:

You may request an additional 30 days for assistance to try to resolve your accessibility problem; or you may file an informal complaint about the accessibility problem with the FCC Enforcement Bureau.

To request an additional 30 days or file an informal complaint, contact the Disability Rights Office at 202-418-2517 (voice) or 202-418-2922 (TTY), by email to dro@fcc.gov, by fax to 202-418-0037, or by mail to the address above. You will need to provide your last name, zip code, and your Request for Dispute Assistance case number.

If you take no action for 60 days after the 30-day time period ends, your case will be closed.

For More Information

For more information about FCC programs to promote telecommunications services for people with disabilities, visit the FCC's Disability Rights Office website. For information about other telecommunications issues, visit the FCC's Consumer website, or contact the FCC's Consumer Center by calling 1-888-CALL-FCC (1-888-225-5322) voice or 1-888-TELL-FCC (1-888-835-5322) TTY; faxing 1-866-418-0232; or writing to:

Federal Communications Commission
Consumer and Governmental Affairs Bureau

Consumer Inquiries and Complaints Division
445 12th Street, SW
Washington, D.C. 20554

For this or any other consumer publication in an accessible format (electronic ASCII text, Braille, large print or audio), please write or call us at the address or phone number above, or send an email to FCC504@fcc.gov.

This document is for consumer education purposes only and is not intended to affect any proceedings or cases involving this subject matter or related issues.

Print Out

Telecommunications Access for People with Disabilities Guide (pdf)

Updated: October 30, 2013
Related Information
Filter
Connect America Fund Provides Over $32 M for Broadband in...
Commission Adopts NPRM to Revitalize AM Broadcast Radio...
Acting FCC Chairwoman Clyburn On Resumption of Commission...
FCC Considers Elimination of the UHF Discount
FCC Proposes the Elimination of the UHF Discount
More »
Related Guides & Help
Cable System Encryption
How to Report a Lost or Stolen Mobile Device
What Companies and Bankruptcy Professionals Must Do to...
Steps For Consumers When Their Phone Company May End Service
Online Public Inspection File Access and Information
More »
Connect
Share this page


DailyDDoSe

Evernote hacked

Critical crypto bug in OpenSSL opens two-thirds of the Web to eavesdropping | Ars Technica

Critical crypto bug in OpenSSL opens two-thirds of the Web to eavesdropping | Ars Technica

Critical crypto bug in OpenSSL opens two-thirds of the Web to eavesdropping

Aurich Lawson / Thinkstock

For a more detailed analysis of this catastrophic bug, see this update, which went live about 18 hours after Ars published this initial post.

Researchers have discovered an extremely critical defect in the cryptographic software library an estimated two-thirds of Web servers use to identify themselves to end users and prevent the eavesdropping of passwords, banking credentials, and other sensitive data.

The warning about the bug in OpenSSL coincided with the release of version 1.0.1g of the open-source program, which is the default cryptographic library used in the Apache and nginx Web server applications, as well as a wide variety of operating systems and e-mail and instant-messaging clients. The bug, which has resided in production versions of OpenSSL for more than two years, could make it possible for people to recover the private encryption key at the heart of the digital certificates used to authenticate Internet servers and to encrypt data traveling between them and end users. Attacks leave no traces in server logs, so there's no way of knowing if the bug has been actively exploited. Still, the risk is extraordinary, given the ability to disclose keys, passwords, and other credentials that could be used in future compromises.

"Bugs in single software or library come and go and are fixed by new versions," the researchers who discovered the vulnerability wrote in a blog post published Monday. "However this bug has left a large amount of private keys and other secrets exposed to the Internet. Considering the long exposure, ease of exploitations and attacks leaving no trace this exposure should be taken seriously."

The researchers, who work at Google and software security firm Codenomicon, said even after vulnerable websites install the OpenSSL patch, they may still remain vulnerable to attacks. The risk stems from the possibility that attackers already exploited the vulnerability to recover the private key of the digital certificate, passwords used to administer the sites, or authentication cookies and similar credentials used to validate users to restricted parts of a website. Fully recovering from the two-year-long vulnerability may also require revoking any exposed keys, reissuing new keys, and invalidating all session keys and session cookies. Members of the Tor anonymity project have a brief write-up of the bug here, and a this analysis provides useful technical details.

OpenSSL is by far the Internet's most popular open-source cryptographic library and TLS implementation. It is the default encryption engine for Apache, nginx, which according to Netcraft runs 66 percent of websites. OpenSSL also ships in a wide variety of operating systems and applications, including the Debian Wheezy, Ubuntu, CENTOS, Fedora, OpenBSD, FreeBSD, and OpenSUSE distributions of Linux. The missing bounds check in the handling of the Transport Layer Security (TLS) heartbeat extension affects OpenSSL 1.0.1 through 1.0.1f.

The bug, which is officially referenced as CVE-2014-0160, makes it possible for attackers to recover up to 64 kilobytes of memory from the server or client computer running a vulnerable OpenSSL version. Nick Sullivan, a systems engineer at CloudFlare, a content delivery network that patched the OpenSSL vulnerability last week, said his company is still evaluating the likelihood that private keys appeared in memory and were recovered by attackers who knew how to exploit the flaw before the disclosure. Based on the results of the assessment, the company may decide to replace its underlying TLS certificate or take other actions, he said.

Attacking from the outside

The researchers who discovered the vulnerability, however, were less optimistic about the risks, saying the bug makes it possible for attackers to surreptitiously bypass virtually all TLS protections and to retrieve sensitive data residing in the memory of computers or servers running OpenSSL-powered software.

"We attacked ourselves from outside, without leaving a trace," they wrote. "Without using any privileged information or credentials we were able steal from ourselves the secret keys used for our X.509 certificates, user names and passwords, instant messages, emails and business critical documents and communication."

They called on white-hat hackers to set up "honeypots" of vulnerable TLS servers designed to entrap attackers in an attempt to see if the bug is being actively exploited in the wild. The researchers have dubbed the vulnerability Heartbleed because the underlying bug resides in the OpenSSL implementation of the TLS heartbeat extension as described in RFC 6520 of the Internet Engineering Task Force.

The OpenSSL vulnerability is the latest to threaten the HTTPS scheme that's the default and often only method for cryptographically protecting websites, e-mail, an other Internet communications from attacks that allow hackers to eavesdrop on end users or impersonate trusted websites. Last month, developers of the GnuTLS library disclosed an equally catastrophic bug that left hundreds of open-source applications open to similar attacks. And in February, Apple fixed an extremely critical vulnerability in the iOS and OS X operating systems that also made it possible for hackers to bypass HTTPS protections.

This post has been updated throughout to add newly available links and details.


Major flaw could let lone-wolf hacker bring down huge swaths of the Internet

Major flaw could let lone-wolf hacker bring down huge swaths of the Internet | Ars Technica UK

Major flaw could let lone-wolf hacker bring down huge swaths of the Internet

A recently disclosed vulnerability in Bind, the most widely used software for translating human-friendly domain names into IP addresses used by servers, makes it possible for lone-wolf attackers to bring down huge swaths of the Internet, a security researcher has warned.

The flaw, which involves the way that Bind handles some queries related to transaction key records, resides in all major versions of the software from 9.1.0 to 9.8.x, 9.9.0 to 9.9.7-P1, and 9.10.0 to 9.10.2-P2. Attackers can exploit it by sending vulnerable servers a malformed packet that's trivial to create. Vulnerable servers, in turn, will promptly crash. There are no indications that the vulnerability is being actively exploited in the wild, and the bug wasn't disclosed until a fix was in place. Still, the critical vulnerability underscores the fragility of Bind, which despite its three decades in use and unwieldy code remains the staple for the Internet's domain name system.

Rob Graham, CEO of penetration testing firm Errata Security, reviewed some of the Bind source code and the advisory that Bind developers issued earlier this week and made this sobering assessment:

BIND9 is the oldest and most popular DNS server. Today, they announced a DoS vulnerability was announced that would crash the server with a simply crafted query. I could use my "masscan" tool to blanket the Internet with those packets and crash all publicly facing BIND9 DNS servers in about an hour. A single vuln doesn't mean much, but if you look at the recent BIND9 vulns, you see a pattern forming. BIND9 has lots of problems—problems that critical infrastructure software should not have.

Its biggest problem is that it has too many features. It attempts to implement every possible DNS feature known to man, few of which are needed on publicly facing servers. Today's bug was in the rarely used "TKEY" feature, for example. DNS servers exposed to the public should have the minimum number of features—the server priding itself on having the maximum number of features is automatically disqualified.

Normally, denial-of-service bugs receive low-severity ratings, but when they're present in servers that form the Internet's very core, the risks are much higher. Graham regularly scans almost the entire Internet to get an estimate of how many servers remain affected by the Heartbleed vulnerability in OpenSSL and other major software weaknesses. He said Bind's code base still isn't as bloated as that of OpenSSL, but it's much slower than it should be despite being written using C and C++. The result: Bind has all the security weaknesses that come with those programming languages without the speed that often justifies their use anyway.

Graham concluded:

The point I'm trying to make here is that BIND9 should not be exposed to the public. It has code problems that should be unacceptable in this day and age of cybersecurity. Even if it were written perfectly, it has far too many features to be trustworthy. Its feature-richness makes it a great hidden master, it's just all those feature get in the way of it being a simple authoritative slave server, or a simple resolver. They shouldn't rewrite it from scratch, but if they did, they should choose a safe language and not use C/C++.

This post originated on Ars Technica