Stories
Slash Boxes
Comments

SoylentNews is people

posted by cmn32480 on Wednesday June 07 2017, @07:24PM   Printer-friendly
from the thats-a-lot-of-zeros dept.

Arthur T Knackerbracket has found the following story:

An eight-year investigation into Dish Networks, a direct-broadcast satellite service provider, resulted Monday in the largest fine ever levied for privacy invasion, with Dish facing a $280m bill.

The US Department of Justice and the Federal Trade Commission brought the case after multiple complaints that people trying to sell the pay-per-view TV provider's services were ignoring the Do Not Call registry and disturbing people who really didn't appreciate the interruption. After investigating the case, the FTC handed it to the DoJ, which filed suit in 2009.

"The National Do Not Call Registry is a popular federal program for the public to reduce the number of unwanted sales calls," said acting assistant attorney general Chad Readler of the Justice Department's Civil Division.

"This case demonstrates the Department of Justice's commitment to smart enforcement of consumer protection laws, and sends a clear message to businesses that they must comply with the Do Not Call rules."

In a 475-page ruling [PDF], US District Judge Sue Myerscough of the Central District of Illinois detailed how Dish Network had run a telemarketing campaign to persuade new customers to sign up and also to call former customers in an attempt to convince them to resubscribe.

Initially Dish ran the calling systems itself, but then outsourced some of the work to retail third-party call centers. Some of these played fast and loose with the rules and called people on the federal Do-Not-Call list who had specified that they didn't want to receive telemarketing calls.

"Dish's reckless decision to use anyone with a call center without any vetting or meaningful supervision demonstrates a disregard for the consuming public," the judge wrote.

-- submitted from IRC


Original Submission

 
This discussion has been archived. No new comments can be posted.
Display Options Threshold/Breakthrough Mark All as Read Mark All as Unread
The Fine Print: The following comments are owned by whoever posted them. We are not responsible for them in any way.
  • (Score: 2) by edIII on Thursday June 08 2017, @04:56PM (5 children)

    by edIII (791) on Thursday June 08 2017, @04:56PM (#522676)

    I actually don't know about ringless voicemail, but I suspect that it is no different. The trick is calling someone in a way that goes direct to voicemail, but that will involve still calling them. If it works differently, than no Caller ID is there.

    Caller ID can be spoofed quite easily since Asterisk will let you populate a whole host of fields that you would think couldn't be populated, much less, be read. In my opinion the telephone companies just gave up and none of that information is reliable at all. ANI was what you would think is in the movies and how the government could trace calls, but it is quite literally abandoned. I was told years ago that most carriers and outfits just treat the whole thing as Caller ID. It's shit.

    No whois is possible, since telephone numbers have no topology. That got thrown out the effin' window years ago with number portability, which is not a bad thing for the consumer. Since the topology is horribly screwed, a whois has no chance. Plus, you can't ban a whole network like that without getting innocent people caught up too. All you can do is ban a single number.

    Correcting it is simple:

    1) Require by law that the ANI is set by SIP providers, specifically those providers that have PSTN infrastructure. Smaller vendors, white-labelers, etc. all have no choice and cannot set the fields anymore, just read them. Some fields will be completely private so that anonymous calls are still possible, with ANI clearly indicating to the providers who is calling who regardless. It's about access to the fields and who can populate them.

    2) Require by law that the ANI can only be populated by the SIP providers with information (DIDS) that their customer has legal rights to. That will force ownership of the numbers themselves, and sadly, no more fun calling up Aunty as the Devil (666).

    If you have both of those you will be able to block individual numbers, and I always recommending blocking true anonymous/unknown at the gateway anyways. An "anonymous" call (Caller ID blocking) is one in which higher level providers still know who is calling, but when it reaches the consumer, that information is stripped and presented with privacy flags. It's an honor based Caller ID blocking service, not simply missing ANI where carriers don't even know who the heck is calling.

    --
    Technically, lunchtime is at any moment. It's just a wave function.
    Starting Score:    1  point
    Karma-Bonus Modifier   +1  

    Total Score:   2  
  • (Score: 2) by kaszz on Thursday June 08 2017, @05:45PM (4 children)

    by kaszz (4211) on Thursday June 08 2017, @05:45PM (#522700) Journal

    Maybe one could exploit the equipment number (EQN) the lies under the dial number (DN) ..? The phone switches got to somehow know how to physically route the call to be able to make it connect at all, and it got to have somewhere to send the return channel.

    The information as to which carriers that were involved along the way could also be helpful. Then there's the information about where to send billing. That also has a destination (address).

    Btw, if anyone has more information on how these voicemail boxes handles caller-id. It would be interesting. Does it record such data. And allow the user to retrieve it later?

    Almost time for "cryptographically signed PSTN number" ..
    And most definitely a PSTN firewall.

    • (Score: 2) by edIII on Thursday June 08 2017, @07:39PM (3 children)

      by edIII (791) on Thursday June 08 2017, @07:39PM (#522761)

      Maybe one could exploit the equipment number (EQN) the lies under the dial number (DN) ..? The phone switches got to somehow know how to physically route the call to be able to make it connect at all, and it got to have somewhere to send the return channel.

      Nope. What you are thinking about is the PSTN infrastructure itself which could be abstracted away by at least 3 providers. I provide phone service for clients, but I'm even myself separated from the switching equipment by at least two companies. Companies that operate their own switches are somewhat rare. Faxage.com is a good example, and I highly recommend them for faxing for that reason. They don't do anything with FoIP, but instead operate actual analog lines in a datacenter. Flowroute is indeed carrier grade, but doesn't. Instead they contract everything out to one of the major carriers on the West coast. I think PacWest or something, and they have the switching equipment and access to the PSTN.

      Asterisk, and SIP in general, has no ability to transmit the EQN number as you suggest. Even if it did, it would be too spoofable. It's a mix of hardware and software, so probably a no go.

      It's also worth mentioning that if I called you 10 times, that not all 10 times may have used the same route or provider. Route aggregators will send your traffic where they can, which means no guarantees on how the traffic got to the destination. That translates into unreliable blocking.

      The information as to which carriers that were involved along the way could also be helpful. Then there's the information about where to send billing. That also has a destination (address).

      NOPE! LOL.

      You would think that, and it would be a reasonable assumption. The reality is that almost everyone has moved on to prepaid and not postpaid. You don't need billing when the authenticated connection itself causes proper billing. To be honest, I'm not even sure how to place a collect call through VoIP, or if it is possible.

      Asterisk has the capability of reverse charges, but that is ONLY when connected to a PRI circuit which means you have analog service brought to the Asterisk box and are no longer using SIP.

      Btw, if anyone has more information on how these voicemail boxes handles caller-id. It would be interesting. Does it record such data. And allow the user to retrieve it later?

      The voicemail boxes I operate go to email, and the headers all contain the Caller ID that called. Reviewing over the phone has the option for an envelope to be read, and that contains the Caller ID and time. I would need to allow a function for people to bypass calling the endpoints and just go to voicemail direct. It's possible and the cellular carriers are known to do that, but the Caller ID information is absolutely present. You may remember some apps that specialized in delivering your message to the person's voicemail without actually calling them? Fairly anti-social, but the same idea :)

      To bypass that entirely would require the ability to say send an email with a voice message to 7145551212@verizon.com. Verizon would need to translate that and present it to you as a voice message, and in those situations there is no Caller ID inforamation. This is similar to how I can send SMS txt messages to you without having any equipment to do so. Just email.

      Almost time for "cryptographically signed PSTN number" ..
      And most definitely a PSTN firewall.

      FUCK NO.

      There is absolutely no such thing possible with the PSTN. The information simply doesn't transmit along those circuits. The firewall is more or less possible already, but only with accurate Caller ID which needs to have the teeth of law to work at all. I may also add.... THOSE COCKSUCKERS IN GOVERNMENT AND VERISIGN ARE SUCKING UP EVERYTHING ON THE PSTN 24/7/365 WITH MEDIATION SWITCHES HANDING IT OVER TO DSNET RUN BY THE F.B.I. Those are the animals more equal than others, and they get to see where everything came from, where it went, who paid for it, what was said, etc. LEO doesn't even have the same access that these bastards at the National Security Theater level get.

      What you want is end-to-end encryption, which exists as zrtp. Just set yourself up the hardware, populate a domain with SRV records, and get ready for end-to-end encrypted SIP connections using strong encryption. It can work as well as encrypted email, DKIM, and SPF.

      The reason we haven't moved towards that... is that there are no phone numbers. People would need to get used to calling somebody at their email address, and then that would mean Google is running their telecommunications. No Bueno. It would need to be side by side along another movement, and that would be to get people their own email addresses, operate their own domains, and handle the SRV records.

      Would you pay for that? Serious question. I'm curious about starting up a business to do that for people. Most people have tablets and smartphones with good Internet access, which means it is a native SIP client away from becoming an advanced telephone service. Or HTML5/WebRTC SIP implementation in the browser. You of course can filter whatever you want, blocking all anonymous and unauthenticated calls. Friends and family will be authenticated, even the pizza joint you call often would be authenticated.

      The piece of shit robocallers, and all those political calls? Gone. Since it is domain based, you get your blocklist you wanted so much. Quite possibly a community operated RBL. Say goodbye to all sorts of debt collectors, scammers, telemarketers, and pranksters that will be relegated to anonymous and unauthenticated calls that never cause ringing, but at most deliver a message. Once.

      --
      Technically, lunchtime is at any moment. It's just a wave function.
      • (Score: 2) by kaszz on Thursday June 08 2017, @11:05PM (2 children)

        by kaszz (4211) on Thursday June 08 2017, @11:05PM (#522832) Journal

        I had a some thought that signed data could be sent as FSK tones before letting the call through.
        Oh and I think a lookup service wouldn't be that hard or costly. And any people letting google run their mail they are hopefully aware that they just sold their life to US "security" orgs.

        • (Score: 2) by edIII on Friday June 09 2017, @12:13AM (1 child)

          by edIII (791) on Friday June 09 2017, @12:13AM (#522861)

          FSK Tones? Again, Nope :(

          It's the same reason why FoIP sucks ass. You're attempting to present an analog circuit in name only. This would be greatly, greatly, dependent upon the codec being used and the bandwidth available. I imagine on many connections the error rate would be high. Counter intuitively, the best codecs are the worst codecs for transmitting FSK. g729 is speech conjugate which is why it sucked so hard for hold music and MP3 streaming was out the question. I think annex B was a little better, and there was/is an attempt to get a different codec going that handles music better. The codecs got very good at compressing speech, but not very good at compressing anything else.

          That being said, I had your idea using DTMF tones. Those *can* be different, and most connections would negotiate DTMF properly to the point where you could get an out-of-band communications channel. I can't imagine it being more than 300-600 baud though, unless we converted the binary stream to decimal. I'm not sure that out-of-band channel could transmit enough data fast enough without call setup times becoming like 1 minute before your connection switches to secured or authenticated.

          However, I think your idea would be very interesting from a steganographic point of view. Have a boring conversation about the Kardasshians for 30 minutes, but then also surreptitiously convey a few paragraphs of coded text. This is somewhat possible because you can program Asterisk on both sides to send/receive DTMF. Can easily become an Asterisk module :)

          dtmf-stego.so

          --
          Technically, lunchtime is at any moment. It's just a wave function.
          • (Score: 2) by kaszz on Friday June 09 2017, @06:46AM

            by kaszz (4211) on Friday June 09 2017, @06:46AM (#522956) Journal

            FSK tones over analog PSTN for Caller-ID is already a established thing. The standard used is half-duplex Bell 202 modem signaling. With a bitrate of 1200 bit/s. Slower speeds could be used if needed. DTMF is not needed. The point is to transfer authentication data for the call while still making use of a existing analog setup. If anything over IP is already in use. Then one might as well send it as bits over IP directly.

            Fax and Mp3 needs a way lot more capacity than 1200 bit/s which why they fail.

            And if you which to go with stenography. Then you might as well use complete audible words as code symbols just like ordinary modems use phase and amplitude constellation diagrams to send symbols instead of directly modulated bits. Or plain pops and noise.

            The authentication could consist of the caller initiators number + UTC time signed with the callers public key. Elliptic curve crypto may be more efficient by using fewer bits. If they match the white list, let through, otherwise reject.