Surfacing peers' workload and speed can reshape collaboration in VR, yet prior work often conflates social cues with environmental load. We isolate the social channel with TRACE-VR, which holds geometry, physics, rules, and timing constant while independently manipulating effort identifiability (traceable vs. anonymous) and peer effort (pace) (high vs. low). In a 2×2 within-subjects study $(n=32)$, each participant worked with nine scripted co-actors for three minutes, transporting 16 crates along a self-chosen path between fixed pickup/drop points; co-actors followed fixed pre-authored routes. We measured intrinsic motivation, social-evaluative load, NASA-TLX, and behavioral/process outcomes. Our findings show that identifiability and higher peer effort (pace) each modestly increased completion rates, with asymmetric effects suggesting partial substitution between accountability cues and normative pace. Perceived monitoring and temporal demand depended on their combination-identifiability raised monitoring at low pace and amplified time pressure at high pace-while composite TLX and finishers' times remained comparable across conditions. Thus, these cues chiefly determine who finishes rather than how fast finishers move. Motivation did not uniformly increase under higher pace. We frame identifiability and pace as partially substitutable levers for shaping social-evaluative experience and facet-level motivation, and outline tempo-aware, accountability-aware guidance for collaborative VR.

In online data-processing services, a user typically hands over personal data to a remote server beyond the user's control. In such environments, the user cannot be assured that the data is protected from potential leaks. We introduce Pave, a new framework to guarantee data privacy while being processed remotely. Pave provides an arbitrary data-processing program with a sandboxed execution environment. The runtime monitor, PaveBox, intercepts all data flows into and out of the sandbox, allowing them only if they do not compromise user data. At the same time, it guarantees that the benign flows will not be hampered to preserve the program's functionality. As the PaveBox is built on top of Intel SGX, a user can verify the integrity and confidentiality of the PaveBox by remote attestation. We provide a formal model of Pave and prove its security and carry out the quantitative analysis with prototype-based experiments.

Transport Layer Security (TLS) is expected to transition to Post-Quantum Cryptography (PQC) to mitigate the threats posed by quantum computing. While PQC ensures long-term security, it significantly increases the TLS handshake latency due to the larger key and signature sizes. Various solutions have been proposed to address this issue; however, they suffer from limitations, such as the necessity of pre-fetching certificates or dependency on prior connections. In this paper, we propose PQTLS-AD, a novel method that leverages the Domain Name System (DNS) to efficiently distribute PQC certificates. By offloading certificate transmission to DNS, PQTLS-AD reduces handshake data overhead, effectively lowering handshake latency. We have developed a PQTLS-AD prototype and conducted extensive experiments. Our results show that PQTLS-AD significantly reduces handshake latency, cutting it by more than one Round-Trip Time (RTT) compared to standard PQTLS.

Digital certificates are crucial for securing Internet communications. Certificates issued by trusted Certificate Authorities (CAs) can be validated by following the chain of trust, consisting of leaf, intermediate, and root certificates. However, such certificate chain structure may not be followed by issuers who are not subject to public monitoring and auditing. This paper takes a first look at certificate chains involving certificates issued by issuers that do not appear in public databases (e.g., major browsers' root stores and CCADB). Utilizing a year's worth of TLS traffic collected from a campus network, we dissect the certificate chain structures and analyze their usage in TLS connections. While we observe positive acts such as the logging of certificates that are issued by issuers outside public databases and anchored to trust roots into Certificate Transparency (CT) logs, we also identify potential misconfigurations by servers where unnecessary certificates are included in the certificate chains, which may lead to validation and connection failures.

Internet protocol specifications, published as Requests for Comments (RFCs) by the IETF organization, are essential to ensuring the interoperability, security, and reliability of the Internet. However, ambiguities in these specifications, particularly logical ambiguities such as inconsistencies and under-specifications, can lead to critical misinterpretations and implementation errors. Unfortunately, such ambiguities remain largely overlooked and challenging to detect with existing tools.In this paper, we present the first systematic study of verified technical errata from Standards Track RFCs over the past 11 years, identifying seven distinct subtypes of logical ambiguities. Building on these insights, we introduce RFCScope, the first scalable framework for detecting logical ambiguities in RFCs. RFCScope employs large language models (LLMs) through a modular pipeline that constructs targeted cross-document context, partitions specifications to preserve semantic integrity, applies bug-type-aware prompts for detection, and filters out false positives using structured reasoning validation.RFCScope uncovers 31 new logical ambiguities spanning all seven subtypes across 14 recent RFCs. Eight of these have been confirmed by RFC authors, with three officially verified as technical errata. Our results demonstrate that RFCScope offers a practical solution for improving the clarity, consistency, and reliability of protocol standards through ambiguity detection.

Distributed Denial-of-Service (DDoS) attacks have remained a significant threat to the Internet for years. One strategy for mitigating these attacks involves requiring clients to solve cryptographic puzzles to control the rate of incoming traffic to a target server. For such a puzzle-based DDoS defense mechanism to be effective, it necessitates robust methods for both distributing puzzles to clients and adjusting puzzle difficulty. In this paper, we introduce a puzzle-based DDoS defense mechanism, DDD, which utilizes the Domain Name System (DNS) for distributing puzzles to clients. The target server disseminates its puzzles by publishing them as a DNS record through its authoritative name server, distributing puzzles to clients via their DNS resolvers. Our design incorporates a monitoring server that continuously monitors incoming traffic to the target and dynamically adjusts puzzle difficulty based on the traffic originating afrom each Autonomous System (AS). This enables AS-specific puzzle difficulty customization, and consequently, traffic control. We have implemented our design into the Linux kernel and showcased its effectiveness in traffic control through prototype-based and controlled experiments.

Transport Layer Security (TLS) is widely recognized as the essential protocol for securing Internet communications. While numerous studies have focused on investigating server certificates used in TLS connections, our study delves into the less explored territory of mutual TLS (mTLS) where both parties need to provide certificates to each other. By utilizing TLS connection logs collected from a large campus network over 23 months, we identify over 2.2 million unique server certificates and over 3.4 million unique client certificates used in over 1.2 billion mutual TLS connections. By jointly analyzing TLS connection data (e.g., port numbers) and certificate data (e.g., issuers for server/client certificates), we quantify the prevalent use of untrusted certificates and uncover potential security concerns resulting from misconfigured certificates, sharing of certificates between servers and clients, and long-expired certificates. Furthermore, we present the first in-depth study on the wide range of information included in CommonName (CN) and Subject Alternative Name (SAN), drawing comparison between client and server certificates, as well as revealing sensitive information.

The DNS HTTPS resource record is a new DNS record type designed for the delivery of configuration information and parameters required to initiate connections to HTTPS network services. In addition, it is a key enabler for TLS Encrypted ClientHello (ECH) by providing the cryptographic keying material needed to encrypt the initial exchange. To understand the adoption of this new DNS HTTPS record, we perform a longitudinal study on the server-side deployment of DNS HTTPS for Tranco top million domains, as well as an analysis of the client-side support for DNS HTTPS through snapshots from major browsers. To the best of our knowledge, our work is the first longitudinal study on DNS HTTPS server deployment, and the first known study on client-side support for DNS HTTPS. Despite the rapidly growing trend of DNS HTTPS adoption, our study highlights challenges and concerns in the deployment by both servers and clients, such as the complexity in properly maintaining HTTPS records and connection failure in browsers when the HTTPS record is not properly configured.

In this paper, we propose methods to estimate the moving direction and size of a target vehicle based on point cloud data detected by high-resolution automotive radar sensor. Previous studies using automotive radar sensors have proposed methods to roughly estimate the moving direction of vehicles, such as left, straight, or right. This study proposes methods to estimate not only the specific moving direction but also the approximate size of the vehicle. First, we use the high-resolution frequency-modulated continuous wave radar to acquire point cloud data for vehicles moving at various angles. In the point cloud data, radar signals are strongly reflected from the side of the vehicle and detected as a line segment. The proposed moving direction and size estimation method is based on line segment extracted from the Hough transform (HT). To extract the line segment from the point cloud data, the Hough transform is used. Using the extracted line segment, methods for estimating the moving direction and size of the vehicle are proposed. And then, the quick hull algorithm is used to estimate the center point of the vehicle to match the position of the target in the coordinate system. Finally, the direction, width, and length of the vehicle estimated from the proposed methods show average errors of 1.94$^\circ$, 4.32%, and 6.32%, respectively. In addition, when compared to the conventional principal component analysis (PCA)-based method, our proposed method exhibits superior performance in terms of estimation accuracy. Moreover, we have validated the effectiveness of the proposed method even in scenarios with multiple vehicles and in noisy road environments.

Establishing secure connections fast to end-users is crucial to online services. However, when a client sets up a TLS session with a server, the TLS handshake needs one round trip time (RTT) to negotiate a session key. Additionally, establishing a TLS session also requires a DNS lookup (e.g., the A record lookup to fetch the IP address of the server) and a TCP handshake. In this paper, we propose ZTLS to eliminate the 1-RTT latency for the TLS handshake by leveraging the DNS. In ZTLS, a server distributes TLS handshake-related data (i.e., Diffie-Hellman elements), dubbed Z-data, as DNS records. A ZTLS client can fetch Z-data by DNS lookups and derive a session key. With the session key, the client can send encrypted data along with its ClientHello, achieving 0-RTT. ZTLS supports incremental deployability on the current TLS-based infrastructure. Our prototype-based experiments show that ZTLS is 1-RTT faster than TLS in terms of the first response time.