Stories with Tag messaging apps

• Dear Apple: Add "Disappearing Messages" to iMessage

  permalink

  Posted: 2025-03-05 23:50:48

  Verbose tl;dr

  The blog post urges Apple to implement disappearing messages in iMessage, arguing it's a crucial privacy feature already offered by competitors like Signal and WhatsApp. The author emphasizes that ephemerality is essential for protecting user privacy against device seizure, data breaches, and unwanted surveillance, citing real-world scenarios where sensitive information shared via iMessage has been exposed. They highlight the inherent risk of permanent message storage and propose that Apple offer user-configurable expiration times, similar to existing self-destructing media features. This would empower users to control the lifespan of their messages and minimize the potential for misuse or unintended exposure.

  The blog post "Dear Apple: Add 'Disappearing Messages' to iMessage Right Now," published on Cryptography Engineering, urgently implores Apple to incorporate an ephemeral messaging feature, akin to those found in platforms like Signal and WhatsApp, into its iMessage service. The author argues that the current state of iMessage, where messages persist indefinitely by default, poses a significant privacy risk. The post emphasizes the increasing importance of digital security and privacy in the face of potential data breaches, legal requests for information, and unauthorized access to devices. The author details the various scenarios in which retained messages could be detrimental, including compromised devices, relationship breakdowns, and changes in personal circumstances. They highlight the potential for sensitive information, shared in confidence, to be exposed and misused in these situations.

  The core proposition is not merely to add a disappearing message option, but to make it the default setting for iMessage. This, the author contends, would significantly enhance user privacy by ensuring that messages are ephemeral unless explicitly preserved. The post dismisses arguments against default ephemerality, such as the potential loss of cherished memories or important information, suggesting that users who wish to retain messages can readily save them through existing mechanisms like screenshots or archiving. The author points to the inconvenience and potential security risks of needing to remember to activate disappearing messages for each conversation, arguing that a default ephemeral setting would offer a much more robust and user-friendly privacy solution. The urgency of the plea is underscored by the increasing prevalence of surveillance and data collection, making the need for strong privacy protections more critical than ever. The post concludes with a direct appeal to Apple, urging the company to prioritize user privacy by making disappearing messages the standard for iMessage communication.

  • Apple
  • iMessage
  • Disappearing Messages
  • Ephemeral Messaging
  • privacy
  • Security
  • messaging apps
  • iOS
  • Feature Request

  Summary of Comments ( 61 )
  https://news.ycombinator.com/item?id=43274416

  Verbose tl;dr

  Hacker News users generally supported the idea of ephemeral messages in iMessage, citing privacy benefits and the existing precedent set by other messaging platforms. Some commenters raised concerns about the potential for misuse, particularly regarding evidence preservation in legal cases or investigations. Others discussed technical implementation details, questioning the reliability and security of such a feature, and suggesting potential solutions like server-side deletion or client-side cryptography. A few pointed out Apple's historical resistance to features perceived as hindering law enforcement access to data, speculating that this might be a factor in the absence of ephemeral messaging in iMessage. Finally, some questioned the effectiveness of disappearing messages given the possibility of screenshots and screen recordings.

  The Hacker News post "Dear Apple: Add "Disappearing Messages" to iMessage" (linking to a blog post advocating for disappearing messages in iMessage) generated several comments discussing the technical and social implications of such a feature.

  Several commenters focused on the potential for misuse and the limitations of disappearing messages as a privacy solution. One commenter pointed out that screenshots could easily defeat the purpose of disappearing messages, while another highlighted the risk of coercion and blackmail, where users might be forced to show disappearing messages before they vanish. The complexity of implementing true disappearing messages across all devices was also raised, with commenters noting the challenges of handling message synchronization and the potential for data recovery from backups.

  A recurring theme was the existing availability of similar functionality in other messaging apps like Signal and WhatsApp, with some commenters questioning the need for Apple to duplicate the feature. There was also a discussion around Apple's historical stance on privacy and security, with speculation about why the company hasn't already implemented disappearing messages. Some suggested it might be due to technical challenges, while others posited that Apple might be hesitant to introduce a feature that could be perceived as facilitating illicit activities.

  Some commenters supported the idea of disappearing messages, emphasizing the benefits for privacy and security in certain situations. They argued that even with the limitations, it could be a useful tool for protecting sensitive information. One user suggested that a more effective approach might be to encrypt messages by default, rather than relying on disappearing messages.

  Overall, the comments section reveals a mixed reception to the idea of disappearing messages in iMessage. While some acknowledge its potential benefits, others express concerns about its limitations and potential for misuse. The discussion highlights the complex trade-offs involved in designing privacy-enhancing features and the need to consider both technical feasibility and social implications.

• X users are unable to post “Signal.me” links

  permalink

  Posted: 2025-02-17 08:52:51

  Verbose tl;dr

  X (formerly Twitter) is currently blocking links to the encrypted messaging app Signal. Users attempting to post links containing "signal.me" are encountering errors or finding their posts failing to send. This block appears targeted, as links to other messaging platforms like WhatsApp and Telegram remain functional. While the reason for the block is unconfirmed, speculation points to Elon Musk's past disagreements with Signal or a potential attempt to bolster X's own encrypted messaging feature.

  The social media platform X, formerly known as Twitter, has implemented a technical measure that prevents users from including links to the encrypted messaging service Signal within their posts. This restriction appears to be specifically targeted at Signal, as links to other competing messaging platforms like WhatsApp and Telegram remain functional. The disruptionist.com article detailing this development suggests that the block is intentional, though the specific motivation behind it remains unclear. X owner Elon Musk has a history of expressing both admiration and criticism towards Signal, further adding to the ambiguity surrounding the decision. Users attempting to share Signal links on X are currently met with an inability to post the content successfully, effectively hindering the promotion and discoverability of Signal on the platform. This limitation applies to both direct links using the "signal.me" domain and disguised attempts, suggesting a proactive filtering mechanism is in place. The article highlights the potential implications of this block, raising concerns about competition and user choice within the social media landscape. While no official statement from X has been issued, the article characterizes the situation as a "soft ban" imposed by the platform.

  • X
  • Twitter
  • Elon Musk
  • signal
  • Signal.me
  • link blocking
  • Censorship
  • social media
  • platform policy
  • Competition
  • messaging apps
  • URL blocking

  Summary of Comments ( 494 )
  https://news.ycombinator.com/item?id=43076710

  Verbose tl;dr

  Hacker News users discussed potential reasons for X (formerly Twitter) blocking links to Signal, speculating that it's part of a broader trend of Musk suppressing competitors. Some suggested it's an intentional move to stifle alternative platforms, pointing to similar blocking of Substack, Bluesky, and Threads links. Others considered technical explanations like an overzealous spam filter or misconfigured regular expression, though this was deemed less likely given the targeted nature of the block. A few commenters mentioned that Mastodon links still worked, further fueling the theory of targeted suppression. The perceived pettiness of the move and the potential for abuse of power were also highlighted.

  The Hacker News post "X users are unable to post “Signal.me” links" discussing the Disruptionist article about X (formerly Twitter) blocking Signal links, has generated a fair amount of discussion with diverse viewpoints.

  Several commenters speculate on the reasons behind the block, with theories ranging from a simple bug to a more deliberate attempt to stifle competition. One commenter suggests it could be an unintentional side effect of measures to combat spam or phishing, pointing out that shortened links are often used for such purposes. This commenter also highlights the possibility that it's related to X's rivalry with other platforms, given Signal's end-to-end encryption and privacy focus which contrasts with X's data collection practices.

  Others posit a more malicious intent, alleging that Elon Musk is actively suppressing competitors. One commenter sarcastically notes the irony of Musk's proclaimed commitment to "free speech" while seemingly censoring a competitor's link. This sentiment is echoed by other users who express concern over the implications of such actions for open communication and competition in the social media landscape.

  Some commenters provide technical perspectives, suggesting potential mechanisms behind the block. One user proposes that it might be a regular expression filter gone awry, accidentally catching "signal.me" in its net. Another suggests that it could be related to link previews or other URL processing features.

  A few commenters offer anecdotal evidence, sharing their own experiences with attempting to post Signal links on X. Some report being unable to post the link directly, while others have found workarounds like adding spaces or using alternative link shorteners.

  The discussion also touches on the broader implications for the future of X, with some users expressing disappointment and predicting a decline in the platform's user base due to such restrictive practices. Others remain more optimistic, suggesting that it might be a temporary glitch that will be resolved soon.

  One comment highlights the perceived hypocrisy in blocking Signal while allowing links to other messaging platforms like Telegram and WhatsApp, speculating that this might be due to their less robust privacy features and thus, less direct competition with X's potential future ambitions in the messaging space.

  Finally, several commenters suggest alternative solutions for sharing Signal links, such as using link shorteners or embedding the link within an image. This reflects a pragmatic approach to circumventing the perceived restriction while continuing to use the platform.

• 0-click deanonymization attack targeting Signal, Discord, other platforms

  permalink

  Posted: 2025-01-21 14:59:44

  Verbose tl;dr

  A security vulnerability, dubbed "0-click," allowed remote attackers to deanonymize users of various communication platforms, including Signal, Discord, and others, by simply sending them a message. Exploiting flaws in how these applications handled media files, specifically embedded video previews, the attacker could execute arbitrary code on the target's device without any interaction from the user. This code could then access sensitive information like the user's IP address, potentially revealing their identity. While the vulnerability affected the Electron framework underlying these apps, rather than the platforms themselves, the impact was significant as it bypassed typical security measures and allowed complete deanonymization with no user interaction. This vulnerability has since been patched.

  A newly disclosed vulnerability, dubbed the "0-click deanonymization attack," poses a significant threat to user privacy on several popular communication platforms, including Signal, Discord, and others employing WebRTC, a real-time communication technology. This attack exploits a subtle flaw in the way these platforms handle IP address leaks within WebRTC connections, allowing a malicious actor to uncover the IP address of a target user without any interaction from the target—hence the "0-click" designation.

  The exploit leverages Session Traversal Utilities for NAT (STUN) and Interactive Connectivity Establishment (ICE) servers, integral components of WebRTC's functionality. These servers facilitate the establishment of peer-to-peer connections by assisting clients in discovering their public IP addresses and traversing network address translation (NAT) gateways. Normally, these IP addresses are exchanged between communicating parties. However, the vulnerability arises from the fact that these platforms inadvertently expose IP addresses to STUN/ICE servers even before a connection is fully established, and crucially, even if the target user declines or ignores a call.

  The attacker initiates a WebRTC connection request to the target user. Even if the target doesn't accept the call, the target's client still interacts with the STUN/ICE servers, revealing its IP address in the process. The attacker, by controlling or monitoring the STUN/ICE server, can passively intercept this communication and capture the target's IP address. This allows for deanonymization, linking the target's online identity on the platform to their real-world location and potentially revealing their true identity.

  This vulnerability is particularly insidious because it requires no action from the target user. Merely receiving a connection request, even an ignored or rejected one, is sufficient for the attack to succeed. This bypasses traditional defenses against IP address leaks, such as disabling WebRTC entirely or using VPNs, as the leakage occurs before these protective measures can effectively intervene. While VPNs might mask the true IP address, the timing correlation between the call attempt and the observed IP address on the VPN server could still provide valuable information to a determined attacker.

  The technical details of the exploit involve manipulating the JavaScript execution within the target's browser to control the flow of WebRTC negotiation and observe the STUN/ICE server interactions. The author of the disclosure emphasizes the simplicity of the attack and its broad applicability to any platform utilizing WebRTC without adequate safeguards. The potential consequences of this vulnerability are serious, ranging from targeted harassment and doxing to large-scale surveillance and privacy breaches.

  • signal
  • Discord
  • deanonymization
  • privacy
  • Security
  • Vulnerability
  • attack
  • metadata
  • 0-click
  • Exploit
  • IP address
  • online privacy
  • communication platforms
  • messaging apps

  Summary of Comments ( 294 )
  https://news.ycombinator.com/item?id=42780816

  Verbose tl;dr

  Hacker News commenters discuss the practicality and impact of the described 0-click deanonymization attack. Several express skepticism about its real-world applicability, noting the attacker needs to be on the same local network, which significantly limits its usefulness compared to other attack vectors. Some highlight the importance of the disclosure despite these limitations, as it raises awareness of potential vulnerabilities. The discussion also touches on the technical details of the exploit, with some questioning the "0-click" designation given the requirement for the target to join a group call. Others point out the responsibility of Electron, the framework used by the affected apps, for not sandboxing UDP sockets effectively, and debate the trade-offs between security and performance. A few commenters discuss potential mitigations and the broader implications for user privacy in online communication platforms.

  The Hacker News post titled "0-click deanonymization attack targeting Signal, Discord, other platforms" generated a significant discussion with a variety of comments. Several commenters focused on the technical aspects of the exploit, highlighting how seemingly innocuous features like generating link previews could be manipulated to leak IP addresses. There's a strong consensus that the core issue stems from servers fetching content from user-supplied URLs without proper safeguards.

  Some commenters questioned the "0-click" nature of the attack, arguing that a user still needs to engage with a message containing a malicious link, even if they don't explicitly click it. Others pointed out that the practicality of the attack is limited by the need for the attacker to control a server capable of logging IP addresses connecting to it.

  The discussion also touched upon the responsibility of different platforms. Some commenters argued that platforms like Signal and Discord should have implemented better protections against this type of attack, while others emphasized that the underlying issue lies with the broader ecosystem of link previews and the lack of standardized security measures.

  A few commenters provided technical insights into potential mitigations, including the use of proxy servers for fetching previews and stricter validation of URLs. The feasibility and potential downsides of these solutions were also debated.

  Some users shared anecdotal evidence of similar attacks or vulnerabilities they've encountered in the past, reinforcing the concern about the potential for abuse of link preview functionality.

  Finally, there was some discussion about the ethical implications of researching and disclosing such vulnerabilities, with opinions varying on the responsible approach to handling such sensitive information. The overall sentiment seems to be one of concern about the potential privacy implications of this attack vector and the need for a broader industry response to address the underlying issues.