Slashdot Mirror

What you say makes sense, so why isn't Goode mentioned as supporting this change? Facts speak loudly.

They are. Google helped create the protocol and is part of the governance authority.
How much more support are you expecting?

Since the article linked from Slashdot is such shit for details, here is a better one from Engadget a couple days ago:
https://www.engadget.com/2019/03/20/att-comcast-test-verified-calls/

The title of that article actually includes the name of the verification protocol:
They believe they're the first to authenticate numbers across providers using the SHAKEN/STIR protocol.

So now you know that's the same subject matter, and you know the two protocol names.
Shaken is "Secure Handling of Asserted information using toKENs"
Stir is "Secure Telephony Identity Revisited"

There is a governance authority setup specifically for the overhead management of those protocols and certificates
https://www.atis.org/sti-ga/
Look at the "Leadership" link to see who runs the show:
https://www.atis.org/sti-ga/leadership/

The board of directors of STI consists of employees and officers of T-Mobile, Google, Wabash Communications, Microsoft, Comcast, Jackson Energy, Verizon, Bandwidth Inc, Western Telecommunications Alliance, and Nex-Tech Wireless ... In that order

The chair is held by AT&T and the vice chair is held by Charter Communications.

What you say makes sense, so why isn't Goode mentioned as supporting this change? Facts speak loudly.

They are. Google helped create the protocol and is part of the governance authority.
How much more support are you expecting?

Since the article linked from Slashdot is such shit for details, here is a better one from Engadget a couple days ago:
https://www.engadget.com/2019/03/20/att-comcast-test-verified-calls/

The title of that article actually includes the name of the verification protocol:
They believe they're the first to authenticate numbers across providers using the SHAKEN/STIR protocol.

So now you know that's the same subject matter, and you know the two protocol names.
Shaken is "Secure Handling of Asserted information using toKENs"
Stir is "Secure Telephony Identity Revisited"

There is a governance authority setup specifically for the overhead management of those protocols and certificates
https://www.atis.org/sti-ga/
Look at the "Leadership" link to see who runs the show:
https://www.atis.org/sti-ga/leadership/

The board of directors of STI consists of employees and officers of T-Mobile, Google, Wabash Communications, Microsoft, Comcast, Jackson Energy, Verizon, Bandwidth Inc, Western Telecommunications Alliance, and Nex-Tech Wireless ... In that order

The chair is held by AT&T and the vice chair is held by Charter Communications.

First: Is there any sort of method in-place wherein a message can be repeatedly broadcast, but only alert subscribers on the first successfully received message?

Yes, that's part of the CBS specification and and the emergency system uses this as well. The messages are broadcast for a set amount of time at a set repetition rate. They also contain serial numbers so that the handsets can distinguish between old and new messages. There is also a provision for sending updates to messages which have already been transmitted.

With what geographic granularity will the broadcasts be sent (or perhaps more properly, received)?

I'm not sure how granular it will be in practice, but it could technically get down to the individual cell level. Most likely, the carriers know which cells approximately serve which zip codes and would group based on that. The specs don't say exactly how this should be done, except that the "Cell Broadcast Center" should determine the affected cell sites for the geolocation (geo-code, polygon, circle) of the emergency message.

Third: Is there any pertinent documentation available that I can ogle?

There really isn't much documentation which is publicly available. Here are a few things, although they're short on real details:
Announcements: FEMA FCC CTIA
Standards (paywalled): ATIS 0700006 Joint ATIS/TIA J-STD-100

Sorry I don't have links to the actual specifications content. For some reason, you have to be a member company or pay for them.

I should have referred to the system by its proper name -- in the U.S., it's called the Commercial Mobile Alert System (CMAS). There are similar systems being set up in other countries which closely follow the U.S. specifications, and those systems should be compatible with CMAS (at least that's the plan).

First: Is there any sort of method in-place wherein a message can be repeatedly broadcast, but only alert subscribers on the first successfully received message?

Yes, that's part of the CBS specification and and the emergency system uses this as well. The messages are broadcast for a set amount of time at a set repetition rate. They also contain serial numbers so that the handsets can distinguish between old and new messages. There is also a provision for sending updates to messages which have already been transmitted.

With what geographic granularity will the broadcasts be sent (or perhaps more properly, received)?

I'm not sure how granular it will be in practice, but it could technically get down to the individual cell level. Most likely, the carriers know which cells approximately serve which zip codes and would group based on that. The specs don't say exactly how this should be done, except that the "Cell Broadcast Center" should determine the affected cell sites for the geolocation (geo-code, polygon, circle) of the emergency message.

Third: Is there any pertinent documentation available that I can ogle?

There really isn't much documentation which is publicly available. Here are a few things, although they're short on real details:
Announcements: FEMA FCC CTIA
Standards (paywalled): ATIS 0700006 Joint ATIS/TIA J-STD-100

Sorry I don't have links to the actual specifications content. For some reason, you have to be a member company or pay for them.

I should have referred to the system by its proper name -- in the U.S., it's called the Commercial Mobile Alert System (CMAS). There are similar systems being set up in other countries which closely follow the U.S. specifications, and those systems should be compatible with CMAS (at least that's the plan).

I did something similar with javascript a few years ago. The javascript is used to codify the RFC BNF, which then generates the regex.

http://www.digitalxen.net/files/emailValidation.js

The other one was a regex for validating phone numbers (at least in the US). It was based on standards from NANPA and ATIX. It worked great until a phone company "accidently" started issuing numbers using one of the exchange codes set aside for testing.

http://www.digitalxen.net/files/phoneValidation.js

Miguel,

I'm not trolling when I ask you: have you read the OOXML proposal or parts of it?

If you have, do you believe the content is a standard? in the light of the comments from various organizations?

If you have not read the OOXML proposal, on who's authority do you base your positive comments?

When talking about platforms if you want to refer to just the OS (or supporting libraries, specifications etc.) then you would say "software platform" and if you want to talk only about the processor (or other supporting hardware) then you would say "hardware platform". Otherwise, in computing, the word platform is understood to mean a particular combination of hardware and software.

Also be aware that cross platform is not the same thing as platform independent.

If you are still confused you may find the following helpful:

http://www.bellevuelinux.org/cross-platform.html
http://www.thefreedictionary.com/platform
http://www.atis.org/tg2k/_platform.html
http://mtechit.com/concepts/platform.html
http://encarta.msn.com/encnet/features/dictionary/ DictionaryResults.aspx?refid=1861738674

• USTA
• ATIS

Let me see if I can explain a few things.

A distributed denial of service attack is usually a consumption of resources that results in the service being unavailable for legitimate users. See Denial-of-service attack for a more complete explanation.

This is in contrast to a security flaw which leads to a compromised system. See security flaw for a definition.

Security flaws can be used in denial of service attacks, but it is difficult to tell from the Grid computing article if this was the case.

Finally, repeat after me. Sendmail is not UNIX. Sendmail is not UNIX. Sendmail is a program that is shipped with UNIX. An administrator may choose to run or not run the program. An administrator may use other mail transport agents.

Here's the summary:

• Sun Grid computer DDoS - at best poor capacity planning
• IE Security flaw - at best poor programming and testing
• Sendmail Security flaw - red herring

This will mean very little in the long run as long as there is a strangle hold simple specifications such as Standard EMI Messaging. EMI Format

The number of phones depends on a number called the Ringer Equivalency Number. (see also here for a quick definition.)

Basically each phone will "use up" one REN to make it ring. Newer phones actually only use 0.5 REN or something like that. A typical hardware box can supply REN of 4 or 5 or something (for example this Linksys box has REN 5). This is more than enough to run most modest domestic setups. If you load the box too much, none of the phones will ring. Then you just turn the ringer off one phone at a time, until the system is able to ring. You can have lots of phones, but only so many will ring when a call comes (the box can only supply so much power). In most homes, this is fine... you can still hear the phone ring if only 4 of the 8 phones are ringing.

The short answer: a decent box should work for a normal home setup (with 4-6 phones). If in doubt, check what the REN number is.

I did't see a provision for refreshing session keys, but I only glanced thru the code and docs and didn't read it in depth.

Its not explicitly mentioned, but "forward secrecy" implies that the session keys change at some point, though it may not change within a single communication. (If Key A and Key B always created the same SessionKey S, then compromising Key A or B would allow an attacker to reveal S (for all past sessions as well) when they talked to each other again.)

> so they are breaking the law and interfering with email

Do tell, what law are they breaking? I must have missed the one which says that ISP's and other electronic mail carriers must deliver all e-mails passing through their systems.

I think that you're right, but I think that the confusion exists because of existing laws concerning common carriers.

Perhaps because you are late to the game. When the only thing available on DVD was video, it was not "versatile".

The USNS Zeus (ARC-7) is the Navy's cable laying and repair ship. The cable is laid mostly on the surface of the bottom, but at vulnerable points and at both ends (near shore) is its ploughed in to the mud/sand on the bottom. When a cut or fault occurs, the location of the fault is determined with a TDR or O-TDR, the same way it works with a land based cable. They know the cable length to the fault and have a survey map of where the cable was layed. It is physicaly located with side-scanning sonar and robotic submersibles, then hooked and brought on deck for repair (each end in case of a break). Once repairs are complete, the cable is unceremoniously shoved over the side, or re-ploughed depending on the location and mission of the cable.

Any technology distinguishable from magic is not sufficiently advanced.

You're right; 10 billion would be plenty of numbers for some time to come. However, the top 3 of the 10 digits is strictly limited to a geographic area; in this case the NYC area codes: 212, 718, 917, 646 and 347. That's not so bad: that gives you 5 times the 7 digit combinations, or about 50 million, right? But wait, some of those 7 digit combinations are illegal. For example, numbers in the range 555-0100 to 555-0199 are reserved for use as "dummy" numbers in the entertainment industry. Some other prefixes are reserved by large corporate PBX's, or because the numbers are blocked by equipment that still remembers the 7-digit dialing days (000-####). That's why the FCC is considering a proposal from ATIS to change that 3 digit prefix (123-####) to 4 digits (1234-####). That would allow us to have about 100,000,000 numbers (less the 5555- numbers, etc.) in each area code --on the order of 500,000,000 numbers for New York City, alone.

You're right; 10 billion would be plenty of numbers for some time to come. However, the top 3 of the 10 digits is strictly limited to a geographic area; in this case the NYC area codes: 212, 718, 917, 646 and 347. That's not so bad: that gives you 5 times the 7 digit combinations, or about 50 million, right? But wait, some of those 7 digit combinations are illegal. For example, numbers in the range 555-0100 to 555-0199 are reserved for use as "dummy" numbers in the entertainment industry. Some other prefixes are reserved by large corporate PBX's, or because the numbers are blocked by equipment that still remembers the 7-digit dialing days (000-####). That's why the FCC is considering a proposal from ATIS to change that 3 digit prefix (123-####) to 4 digits (1234-####). That would allow us to have about 100,000,000 numbers (less the 5555- numbers, etc.) in each area code --on the order of 500,000,000 numbers for New York City, alone.

Honestly, do you really believe that the switch to digital radio will fix that? Those are bandwidth issues not signal issues.

(makes one wonder what are we going to do once everything we do is in binary)

Interestingly enough; a digital signal is either there - in all of the orignal transmitted quality - or it's not. In TV it's called the Cliff Effect and is part of why digital is becoming popular. Ever have a radio or TV station where the signal was full of snow and static? That won't happen with digital signals.

So, once devices such as this transmit a digital signal; it may be poorer quality ( = lesser bandwidth, say 64kHz compared to 128) than a "real" FM transmission station, but you'll recieve the signal in as high of quality as it sent out, thanks to the Cliff effect.

Tim's point about Kapor and Lotus 1-2-3 is very salient and timely. Think about it. Linux has reached a point where it threatens commercial products like NT for market space, forces OSS business models into the mainstream, pressures closed-source vendors to provide products for Linux (even if they don't want to participate in the OSS process), and generally returned a great deal of industry power to the hands of the consumer. The computing community is clearly ready for the next step -- the OSS killer app phase.

What is the killer app? Apache? Samba? There's no obvious answer, and Tim touches on this with his discussion of HTML. But he's still a little hung-up on the "web-based infoware" thing. I think the killer app that we're all waiting for isn't an app at all. The Linux/GNU/OSS movement has caused major shifts in the philosophical as well as computing landscape. The killer "app" is really the arrival of portable data. We've so commoditized the applications that it doesn't matter whether you're using Word, Wordperfect, Staroffice, Claris, a web-app, or who-knows-what else. What matters is how difficult it is to share information. Most productivity app vendors have decided to mimic MS Office 97 formats by providing converters, allowing in-format editing of MS-format documents, or using HTML as a native format, but these are only stopgaps. The next hurdle is to apply the OSS philosophy to content (data formats, interchage standards, protocols, translations), not just structure (operating systems, apps, web apps).

We're starting to see this a little, and it seems to be following XML. GNOME spreadsheets are stored in an XML format. User-friendly XML text editors such as XMetal and XML Spy are starting to show up for Windows. Oracle is starting to provide mainstream support for XML-based EDI. Consciously or not, we're beginning to think of common content formats as a global necessity. The problem, of course, is that these standards are typically built by glacially-slow concensus in a private industry forum. For example, the DTD for telecom information interchange that I was briefly involved with is maintained by the Information Products Interchange (IPI) subcommittee of the Telecommunications Industry Forum (TCIF), which is a subcommittee of the Alliance for Telecommunications Industry Solutions (ATIS). [See http://www.atis.org]

Buried in such a hierarchy, it's a wonder that the IPI's Telecommunications Interchange Markup standard (TIM, an XML-compliant SGML DTD) evolved at all. It's success is due primarily to the efforts of a few dedicated individuals. Sound familiar? This parallels the way that Linus et al manage updates to Linux kernel code. We're used to thinking of open source in terms of Linux and GNU software. Tim thinks of it as inclusive of web apps touches on interchange. We need to open that up to specifically include content. If you'll forgive the analogy, I think we've covered the nouns, and we have to think about the verbs -- apply OSS to the things we DO and not just the tools we use or places to do them. Open source organizational clearinghouses and listservs need to start providing for open source development of data formats and standards, not just apps. (Not to say that anyone working on OSS XML tools for Linux should slow down in the slightest!)

Those of us interested in data interchange, which includes anyone who ever shares so much as a text file, need to organize and communicate. If there's no standard for your data, develop one. If there is, contribute, review, and use it. (Think about harnessing all the wasted effort consumed by MS Office file format woes!) Don't let a vendor hold your data hostage in a proprietary format. The momentum behind Linux and other GNU software is driven by quality of the code and openness. Apply that to content, and the world will become a much better place.

Jon

Tim's point about Kapor and Lotus 1-2-3 is very salient and timely. Think about it. Linux has reached a point where it threatens commercial products like NT for market space, forces OSS business models into the mainstream, pressures closed-source vendors to provide products for Linux (even if they don't want to participate in the OSS process), and generally returned a great deal of industry power to the hands of the consumer. The computing community is clearly ready for the next step -- the OSS killer app phase.

What is the killer app? Apache? Samba? There's no obvious answer, and Tim touches on this with his discussion of HTML. But he's still a little hung-up on the "web-based infoware" thing. I think the killer app that we're all waiting for isn't an app at all. The Linux/GNU/OSS movement has caused major shifts in the philosophical as well as computing landscape. The killer "app" is really the arrival of portable data. We've so commoditized the applications that it doesn't matter whether you're using Word, Wordperfect, Staroffice, Claris, a web-app, or who-knows-what else. What matters is how difficult it is to share information. Most productivity app vendors have decided to mimic MS Office 97 formats by providing converters, allowing in-format editing of MS-format documents, or using HTML as a native format, but these are only stopgaps. The next hurdle is to apply the OSS philosophy to content (data formats, interchage standards, protocols, translations), not just structure (operating systems, apps, web apps).

We're starting to see this a little, and it seems to be following XML. GNOME spreadsheets are stored in an XML format. User-friendly XML text editors such as XMetal and XML Spy are starting to show up for Windows. Oracle is starting to provide mainstream support for XML-based EDI. Consciously or not, we're beginning to think of common content formats as a global necessity. The problem, of course, is that these standards are typically built by glacially-slow concensus in a private industry forum. For example, the DTD for telecom information interchange that I was briefly involved with is maintained by the Information Products Interchange (IPI) subcommittee of the Telecommunications Industry Forum (TCIF), which is a subcommittee of the Alliance for Telecommunications Industry Solutions (ATIS). [See http://www.atis.org]

Buried in such a hierarchy, it's a wonder that the IPI's Telecommunications Interchange Markup standard (TIM, an XML-compliant SGML DTD) evolved at all. It's success is due primarily to the efforts of a few dedicated individuals. Sound familiar? This parallels the way that Linus et al manage updates to Linux kernel code. We're used to thinking of open source in terms of Linux and GNU software. Tim thinks of it as inclusive of web apps touches on interchange. We need to open that up to specifically include content. If you'll forgive the analogy, I think we've covered the nouns, and we have to think about the verbs -- apply OSS to the things we DO and not just the tools we use or places to do them. Open source organizational clearinghouses and listservs need to start providing for open source development of data formats and standards, not just apps. (Not to say that anyone working on OSS XML tools for Linux should slow down in the slightest!)

Those of us interested in data interchange, which includes anyone who ever shares so much as a text file, need to organize and communicate. If there's no standard for your data, develop one. If there is, contribute, review, and use it. (Think about harnessing all the wasted effort consumed by MS Office file format woes!) Don't let a vendor hold your data hostage in a proprietary format. The momentum behind Linux and other GNU software is driven by quality of the code and openness. Apply that to content, and the world will become a much better place.

Jon