Subject: Re: [stir] A 4474 that will work through SBCs (generally/potentially)

From: Henning Schulzrinne <[email-masked]>
Date: Thu, 6 Jun 2013 22:16:22 -0400

I was thinking of the latter - add something to the textual display to indicate trust.

On Jun 6, 2013, at 6:02 PM, Hadriel Kaplan wrote:

> 
> If you mean the terminal-adapter/gateway inserting the extra character onto the caller-id sent on the POTS line itself (ie, in the FSK), then I think it would screw up some POTS phones that try to match received CID to their local address books, or that provide a local call-back feature. (my POTS phone at home does both of those things, for example)
> 
> But for the callerid+name type POTS lines (ie, MDMF type as opposed to SMDF) you could put a character in the name string if there's room, instead of in the number field.
> 
> -hadriel
> 
> 
> On Jun 6, 2013, at 5:09 PM, "Rosen, Brian" <[email-masked]>
> wrote:
> 
>> This is a case where a smarter device could be attractive, rather than a POTS telephone (through a terminal adapter).  Smarter devices could display information that told the user more about the call.
>> 
>> While I don't see POTS service Caller-Id changing, you could imagine having a TAD that checked the sig and put a character in front of the name/number that was a good/bad/no data indicator of the sig check.
>> 
>> Brian
>> On Jun 6, 2013, at 5:03 PM, "DOLLY, MARTIN C" <[email-masked]>
>> wrote:
>> 
>>> I agree. But the interface to the user needs to be easily understood to the user, independent of device.
>>> 
>>> -----Original Message-----
>>> From: [email-masked] [mailto:[email-masked]] On Behalf Of Jean-Francois Mule
>>> Sent: Wednesday, June 05, 2013 1:18 PM
>>> To: [email-masked]
>>> Subject: Re: A 4474 that will work through SBCs (generally/potentially)
>>> 
>>> There may exist options for presenting unsigned calls to end-users and
>>> allow them to decide on a call rejection.
>>> 
>>> I would encourage the separation of end-users from service providers and
>>> hope the technical solution can enable multiple policies for SSPs and
>>> regulators to choose from (SIP Service Providers could be enterprises,
>>> SMS, service operators, or my asterisk software).
>>> 
>>> Jean-Francois.
>>> ---
>>> Jean-François Mulé
>>> Mobile:+1-415-881-7178
>>> mailto:[email-masked]
>>> 
>>> 
>>> 
>>> On 06/05/2013 08:13, "Henning Schulzrinne" <[email-masked]> wrote:
>>> 
>>>> You might want to start to have that discussion with your public policy
>>>> folks soon. I'd be happy to facilitate meetings on this topic as needed.
>>>> There are intermediate steps, beyond blanket rejection, such as rejecting
>>>> calls where the number is in the "must be signed list" and the call
>>>> isn't. This deals with a lot of worst kinds of impersonation abuses.
>>>> 
>>>> On Jun 5, 2013, at 8:54 AM, "DOLLY, MARTIN C" <[email-masked]> wrote:
>>>> 
>>>>> I "believe" that we (Tier 1/2) would need some permission (regulation)
>>>>> to not accept unsigned calls.
>>>>> 
>>>>> On the other hand, what is grandma is calling from one of those smaller
>>>>> providers, if we do not forward those calls to the destination, our
>>>>> customer will complain.
>>>> 
>>>> 
>>>> 
>>>> #############################################################
>>>> This message is sent to you because you are subscribed to
>>>> the mailing list <[email-masked]>.
>>>> To unsubscribe, E-mail to: <[email-masked]>
>>>> To switch to the DIGEST mode, E-mail to <[email-masked]>
>>>> To switch to the INDEX mode, E-mail to <[email-masked]>
>>>> Send administrative queries to  <[email-masked]>
>>>> 
>>> 
>>> 
>>> 
>>> #############################################################
>>> This message is sent to you because you are subscribed to
>>> the mailing list <[email-masked]>.
>>> To unsubscribe, E-mail to: <[email-masked]>
>>> To switch to the DIGEST mode, E-mail to <[email-masked]>
>>> To switch to the INDEX mode, E-mail to <[email-masked]>
>>> Send administrative queries to  <[email-masked]>
>>> 
>>> 
>>> 
>>> #############################################################
>>> This message is sent to you because you are subscribed to
>>> the mailing list <[email-masked]>.
>>> To unsubscribe, E-mail to: <[email-masked]>
>>> To switch to the DIGEST mode, E-mail to <[email-masked]>
>>> To switch to the INDEX mode, E-mail to <[email-masked]>
>>> Send administrative queries to  <[email-masked]>
>>> 
>> 
>> 
>> 
>> #############################################################
>> This message is sent to you because you are subscribed to
>> the mailing list <[email-masked]>.
>> To unsubscribe, E-mail to: <[email-masked]>
>> To switch to the DIGEST mode, E-mail to <[email-masked]>
>> To switch to the INDEX mode, E-mail to <[email-masked]>
>> Send administrative queries to  <[email-masked]>
>> 
> 
> 
> 
> #############################################################
> This message is sent to you because you are subscribed to
>  the mailing list <[email-masked]>.
> To unsubscribe, E-mail to: <[email-masked]>
> To switch to the DIGEST mode, E-mail to <[email-masked]>
> To switch to the INDEX mode, E-mail to <[email-masked]>
> Send administrative queries to  <[email-masked]>
> 
>

---

From: Dave Crocker <[email-masked]>
Date: Fri, 07 Jun 2013 05:41:45 +0200

> I was thinking of the latter - add something to the textual display to indicate trust.

The human factors design issues that the suggestion invokes 
unfortunately are far more challenging and far less reliable than anyone 
would wish.

At the least, it's a topic that calls on UX/HCI expertise, rather than 
protocol design expertise.  They are very, very different domains of 
knowledge.  As a touchstone, I'll note that it's reasonable to assume 
that it's good to always give more information, but the assumption is wrong.

The dominant model in use for Internet anti-abuse work on adding 
trust-related mechanisms is to target use by filtering engines by a 
handling agent (possibly including the receiving user agent, but out of 
sight of the actual user.)

d/

-- 
Dave Crocker
Brandenburg InternetWorking
bbiw.net

---

From: Dan York <[email-masked]>
Date: Fri, 7 Jun 2013 13:01:49 +0000

>unfortunately are far more challenging and far less reliable than anyone

100% agreed!

>that it's good to always give more information, but the assumption is

Right. And as we've seen in the consumer space, it is often the simplest
interfaces and user experiences that gain the widest adoption.  Whether
you like Apple or not, their "less is more" design focus has brought about
mobile devices that are extremely easy to use and widely adopted - and
that same design ethic is visible in many Android and other devices.
Similarly, as a long-time user of Skype, I severely detested some of their
recent UI changes that removed functionality and made the UI simpler...
but I also found that a number of non-techie people I know really liked
the newer simpler UI.

>sight of the actual user.)

When we were have a similar debate back in 2008, I wrote a draft
summarizing a number of the discussions we were having then:

http://tools.ietf.org/html/draft-york-sip-visual-identifier-trusted-identit
y-01

At that time, we didn't have all the many more devices that we do today...
"smart" TVs, smart phones, and more.  We were just thinking about
softphones and "hard" IP phones.

Over the 5 years since, though, I've come to question whether visual
identifiers are really useful.  I often see people who just click through
web browser certificate warnings to get to their web page... and don't
fully pay attention to whether they have a lock icon or whatever else the
browser uses.

When you have a visual identifier, you also then need to have another
layer of security around that identifier to be sure that an attacker can't
spoof the identifier on a particular device.

I don¹t know the answer... and I do agree with Dave that this particular
question is one that probably merits assistance from people who are
steeped in the UX/HCI world.

Dan

P.S. We've been having this same debate off and on within DNSSEC circles -
should there be a visual identifier within, say, a web browser, when the
browser is connecting to a site that has a DNSSEC-signed domain?  Should
there be warning messages?  Or should it just fail to connect?  What is
the right balance?

--
Dan York
Senior Content Strategist, Internet Society
[email-masked] <mailto:[email-masked]>   +1-802-735-1624
Jabber: [email-masked] <mailto:[email-masked]>
Skype: danyork   http://twitter.com/danyork

http://www.internetsociety.org/deploy360/