Dark Reading is part of the Informa Tech Division of Informa PLC

This site is operated by a business or businesses owned by Informa PLC and all copyright resides with them.Informa PLC's registered office is 5 Howick Place, London SW1P 1WG. Registered in England and Wales. Number 8860726.

Comments
The Implications Behind Proposed Internet Privacy Rules
Newest First  |  Oldest First  |  Threaded View
Shantaram
50%
50%
Shantaram,
User Rank: Ninja
4/19/2017 | 9:11:54 AM
Re: 192.168.0.1
Very intуresting and detailed post. Thanks for sharing
dritchie
50%
50%
dritchie,
User Rank: Strategist
4/18/2017 | 3:31:53 PM
Re: Some bold claims here
Not only that, but the original poster works for a company that seems to try to help companies deliver unwanted commercial email (i.e. SPAM), so limiting the ability of providers to sell him information hurts his bottom line.
dritchie
50%
50%
dritchie,
User Rank: Strategist
4/18/2017 | 3:28:40 PM
Re: Some bold claims here
Not only that, but the poster works for a company that seems to try to help companies deliver unwanted commercial email (i.e. SPAM).
guy_montag
100%
0%
guy_montag,
User Rank: Apprentice
4/18/2017 | 11:10:24 AM
Some bold claims here
The author makes some bold claims here but doesnt make a very good case for them. Whats the FTC's track record in actually protecting privacy? How do common carrier privacy protections "stiffle antispam and malware detection" any more than TLS does? How would the FTC be less susceptible to regulatory capture than the FCC? Regultory capture is imo, the strongest case against FCC action but this article doesnt even mention it.

The only arguments here seems to be "the ftc does a great job, take my word for it" and also that adverstisers "already know everything" so who cares? That undercuts the whole part about the glories of self-regulating ISP's and the past work of the FTC. Never mind the fact that those that do deep packet inspection are ripe targets for attack even if they dont voluntarily sell the data to third parties.

The article also ignores the major impetetus for the Title II classification, namely, net neutrality. Pretending common carrier reclassification was just about privacy is silly at best, disengenuous at worst.

All in all, this article doesnt pass the laugh test. Isps are local monopolies, comcast is not google, and vpn's wont protect you. 


AI Is Everywhere, but Don't Ignore the Basics
Howie Xu, Vice President of AI and Machine Learning at Zscaler,  9/10/2019
Fed Kaspersky Ban Made Permanent by New Rules
Dark Reading Staff 9/11/2019
Register for Dark Reading Newsletters
White Papers
Video
Cartoon Contest
Current Issue
7 Threats & Disruptive Forces Changing the Face of Cybersecurity
This Dark Reading Tech Digest gives an in-depth look at the biggest emerging threats and disruptive forces that are changing the face of cybersecurity today.
Flash Poll
The State of IT Operations and Cybersecurity Operations
The State of IT Operations and Cybersecurity Operations
Your enterprise's cyber risk may depend upon the relationship between the IT team and the security team. Heres some insight on what's working and what isn't in the data center.
Twitter Feed
Dark Reading - Bug Report
Bug Report
Enterprise Vulnerabilities
From DHS/US-CERT's National Vulnerability Database
CVE-2019-4147
PUBLISHED: 2019-09-16
IBM Sterling File Gateway 2.2.0.0 through 6.0.1.0 is vulnerable to SQL injection. A remote attacker could send specially-crafted SQL statements, which could allow the attacker to view, add, modify or delete information in the back-end database. IBM X-Force ID: 158413.
CVE-2019-5481
PUBLISHED: 2019-09-16
Double-free vulnerability in the FTP-kerberos code in cURL 7.52.0 to 7.65.3.
CVE-2019-5482
PUBLISHED: 2019-09-16
Heap buffer overflow in the TFTP protocol handler in cURL 7.19.4 to 7.65.3.
CVE-2019-15741
PUBLISHED: 2019-09-16
An issue was discovered in GitLab Omnibus 7.4 through 12.2.1. An unsafe interaction with logrotate could result in a privilege escalation
CVE-2019-16370
PUBLISHED: 2019-09-16
The PGP signing plugin in Gradle before 6.0 relies on the SHA-1 algorithm, which might allow an attacker to replace an artifact with a different one that has the same SHA-1 message digest, a related issue to CVE-2005-4900.