Apple Health data is end-to-end encrypted, even without using ADP. They don't have access to it: https://support.apple.com/en-us/102651

That is cute, but if big tech goes out of its way to get specific permissions to do something, I am going to assume it is not in my best interests.

Sure, Apple is less bad than many others, but that does not mean they are trustworthy.

I assumed it was to update your sleep stats in health.

> intercept SMS including the verification codes sent by apps like WhatsApp

For anyone worried, this approach:

1) Breaks the existing phone from receiving WhatsApp messages, so you can notice that behavior

2) Can be prevented by setting up a WhatsApp pin in your settings

Probably these were addressed way too late. Developers are the last to know their backdoors surprisingly.

I don't need something to protect the privacy of others from me, I need something to protect my privacy from others. The majority of people who use smart glasses are not going to be using this - where is the product that will protect me from them?

Masks work.

> Make an RSA key of 4096 bits. Call it your personal key.

This is bad advice - making a 4096 bit key slows down visitors of your website and only gives you 2048 bits of security (if someone can break a 2048 bit RSA key they'll break the LetsEncrypt intermediate cert and can MITM your site). You should use a 2048 bit leaf certificate here

My webhost only supports RSA keys, so I use an RSA-4096 key just to annoy them into supporting EC keys.

The key in question is the acme account key though, correct?

Amateur question: does a 4096 not give you more security against passive capture and future decrypting? Or is the intermediate also a factor in such an async attack?

> does a 4096 not give you more security against passive capture and future decrypting?

If the server was using a key exchange that did not support forward secrecy then yes. But:

    % echo | openssl s_client -connect rachelbythebay.com:443 2>/dev/null | grep Cipher
    New, TLSv1.2, Cipher is ECDHE-RSA-AES256-GCM-SHA384
    Cipher    : ECDHE-RSA-AES256-GCM-SHA384

^ they're using ECDHE (elliptic curve diffie hellman), which is providing forward secrecy.

I thought FS only protected other sessions from leak of your current session key. How does it protect against passive recording of the session and later attacking of the recorded session in the future?

If using a non-FS key exchange (like RSA) then the value that the session key is derived from (the pre-master secret) is sent over the wire encrypted using the server's public key. If that session is recorded and in the future the server's private key is obtained, it can be used to decrypt the pre-master secret, derive the session key, and decrypt the entire session.

If on the other hand you use a FS key exchange (like ECDHE), and the session is recorded, and the server's private key is obtained, the session key cannot be recovered (that's a property of ECDHE or any forward-secure key exchange), and none of the traffic is decryptable.

Thanks I think I understand better now!

No, my GP is correct: if the server's RSA private key is compromised it does not allow decryption of any previously-recorded sessions.

You would need to compromise the _ephemeral session key_ which is difficult because it is discarded by both parties when the session is closed.

Compromising the RSA key backing the certificate allows _future_ impersonations of the server, which is a different attack altogether.

The certificate is for authentication of the server. It has nothing to do with the encryption of the data.

Basically forward secrecy is where both the sender and receiver throw away the key after the data is decrypted. That way the key is not available for an attacker to get access to later. If the attacker can find some way other than access to the key to decrypt the data then forward secrecy has no benefit.

185 days before 3/15/2025 is 9/11/2024. There were these IPOs around that time (all Nasdaq) [1]:

- 9/10: TDTH

- 9/10: XCH

- 9/12: GLXG

- 9/12: FVN

[1]: https://stockanalysis.com/ipos/2024/

Unless details were intentionally changed that narrows it down to two companies that are not US based, despite being traded on Nasdaq. The other two are a ETF and SPAC

Worth noting, because many people seem to assume these folks are based in SV

Because other Sv tech companies some us have worked for have been equally and intentionally shady

It's not those companies. There is a typo in the original post. 3/15 is before 185 days.

> If that's the case, then there's not much to see here

They could have demonstrated the POC without sending data about the installing host, including all your environment variables, upstream. That seems like crossing the line

If I get a new car I'm just taking the modem out.

If an insurance company can’t find data on you when they expect it, won’t they just charge you the high risk premium?

If you won’t tell them whether you have a car alarm or a secure garage they just assume you don’t.

One of the automakers in the article claims that voids your warranty. It may or may not but enjoy the legal battle should you ever need to make a claim.

It does not. There are laws against voiding a warranty based on aftermarket modifications made by the end user. This is the case in the USA at least.

Chrome/Firefox/curl do allow exporting this by setting the `SSLKEYLOGFILE` environment variable, but as another poster points out this would let anyone with access to your hard drive decrypt your historical traffic

I continue to request my reports via certified mail to the annualcreditreport address, and this time for the first year Equifax just ... didn't reply. Completely ignored my request.

Submit a complaint via the CFPB. They most certainly will then respond.

I had a frustrating experience trying to obtain my consumer report from Early Warning Services, a less-known alternative to Chex Systems. Their process for requesting a report was unnecessarily complex and seemed designed to discourage users.

Initially, I had to navigate to a hidden webpage, which then directed me to a PDF form. This step alone was convoluted. After filling out the form, I discovered a line within the PDF that provided a link to a consumer portal, which looked like it hadn't been updated since the early 2000s.

The next step required me to create an account on this outdated portal, upload the completed PDF, and wait for a response.

However, my troubles didn't end there. For reasons unknown to me, my account was suddenly deleted. When I reached out to their IT support for help, they were clueless about the reason behind this issue.

Fed up with the lack of support and transparency, I decided to file a complaint with the Consumer Financial Protection Bureau (CFPB). To my surprise, this action prompted a swift response from Early Warning Services. Within just two days of filing the complaint, they sent me my consumer report.

Do you have your credit frozen with just Equifax, or something? Just trying to think of vanilla (i.e. incompetence rather than malice) reasons to explain this. Of course, it goes without saying that they all suck...

It's a common bypass of server side request forgery filtering. Backends will try to validate that a user-submitted url doesn't resolve to an internal IPv4 address, but they'll happily allow an IPv6 mapped version for the same IPv4 address.