calebio · HackerTrans

hace 11 horasdiscuss

Google/Waymo + Uber/Otto comes to mind here with Anthony Levandowski.

hace 19 díasdiscuss

I think there's a middle ground of people who just are not interested in building or upgrading a gaming computer (or just don't like their typical form factor in the ready to go out of the box gaming PCs) but also don't want the completely closed off ecosystem of a console.

I think if the Xbox ended up being more like the Steam Machine (i.e. more like a PC) then this middle ground that the Steam Machine sells to would probably go away as I don't think the group of folks who care that it's Linux based is high enough to support production.

calebio

hace 19 díasdiscuss

Did you just stop scrolling at the first group of people to come and make this comment?

calebio

hace 21 díasdiscuss

You can easily burn through hundreds of dollars researching one or two relatively small court cases. I don't think you should be indigent or go to the courthouse/public library to avoid spending hundreds of dollars for that small amount of research.

calebio

hace 21 díasdiscuss

Stalking has a specific definition that I'm not sure would apply here.

Your behavior on the internet is certainly tracked by corporations. Your phone's radio addresses were (are) tracked as you walk by things. None of that rises to the level of "stalking" as we commonly refer to it.

calebio

hace 21 díasdiscuss

No, it's not. You are not protected from a private company that owns ALPRs as part of the 4th amendment.

The government purchasing data from 3rd parties (the third-party doctrine) doesn't violate your 4th amendment rights against unreasonable searches and seizures. You voluntarily gave the data to a 3rd party and the 3rd party voluntarily sold that data to the government.

The carve out is really only for phone GPS data (cell tower connection logs) as specified in Carpenter v. United States.

So just like you're not protected from AT&T selling your call logs to the government, you're not protected from Flock selling access to their images of your car (at this time).

calebio

hace 21 díasdiscuss

> That's not what I'm seeing. My mom always wanted Google to just answer questions, and now ChatGPT can. She uses it enough in her daily life that she bought a subscription.

Reminds me a lot of AskJeeves :)

calebio

hace 23 díasdiscuss

> A lower resolution tracking is still tracking though. Spatial resolution is low/fixed doesn’t change the fact that I was tagged using the personally identifiable plate and my movements were tracked across the town.

You're not wrong that it's still tracking. Though, whether it's tracking or not isn't really the thing up for debate here.

In my head it's:

A) Whether you have a reasonable expectation of privacy from a person or company when driving your car with a personally identifiable plate on a public street.

B) Is it your data that is being searched or is it the data of the company who owns the ALPR? Is it a violation of your rights for that data to be searched?

The decision in Carpenter is extremely narrow and doesn't cover things like cameras or non-targeted tower dumps.

It will be interesting to see how this turns out.

It's also similar to the ever growing network of toll road cameras and bridge/highway cameras that capture an image of each car + driver's face.

calebio

hace 23 díasdiscuss

I think the question may instead be:

> do you have the right to not have [a private company] tracking your movements and keeping logs of everywhere you’ve been for months or years, especially when you’re not currently suspected of any crime?

And

> do you have the right for the government to not purchase that data from [a private company]?

calebio

hace 23 díasdiscuss

While Carpenter v. United States (2018) somewhat changed the rules regarding the "purchase" of third-party data in the context of an investigation, it seems like the ALPRs do not violate the 4th amendment the same way that the decision in Carpenter decided.

Since ALPRs are effectively fixed in a geographic place with gaps and AFAIK do have relatively low retention periods (I need to double check this), they don't offer the same "whole person movement" data that a phone would when described in Carpenter.

Will be interesting to see how this goes, and I'm sure ALPR density may play a part in it, but for now I don't think it violates someone's privacy under the 4th amendment.

This debate also ties heavily into one around the surveillance network created via camera networks like Ring.

calebio

hace 29 díasdiscuss

The L-Taraval, at least historically, was not reliable between downtown and the outer sunset (past Sunset Blvd).

calebio

hace 3 mesesdiscuss

Any idea if/when this would be coming to GHE? I know the release cycle is way different but curious about your thoughts.

calebio

hace 3 mesesdiscuss

I miss the Phabricator review UI so much.

calebio

hace 4 mesesdiscuss

Have they even filed the forms yet or is this another instance of "let's tweet a thing and let some of the public believe Y (new) while X (old) is actually still true"?

calebio

hace 4 mesesdiscuss

Historically, availability was very different between the two countries when we're specifically talking about purchasing SIMs for questionable activity.

Physically acquiring the SIMs is only one part of the process as they're pretty worthless without going through the activation process.

Prior to this year in Mexico (which introduced ID-based regulations around SIM purchase/activation), you could buy a SIM at a remote gas station, a data package in cash, and activate it without giving your name/email/etc. Now, in 2026, you have to show an ID/passport to do that.

The U.S. doesn't have a federal regulation (as far as I know) for this. That level of network protection is usually at the provider level. However, activating the SIM almost always requires an email or existing phone number and not just purchase/possession of the SIM+top-up card. Purchasing the top-up card sometimes can be done in cash, other times requires a pre-paid debit which has its own limitations/regulations due to a mix of KYC/AML. But applying said top-up card usually still requires at least some form of identity verification. For some of the top national providers, and I'm not sure what model they use to gauge risk to make this decision, they even require an SSN (for prepaid!) and run some form of a check on you (I'm not entirely sure if it's a soft credit check or what).

calebio

hace 4 mesesdiscuss

Not a direct answer to your reuqestion re: questionable activity, but for me it's more about ease of access.

A SIM in the U.S. is significantly more difficult to acquire than a SIM in Mexico/many other countries.

E.g.

- Limit on # of SIMs purchased at retailers, low ability to use cash to purchase them, generally always on camera

- SIMs locked up behind the counter at lots of major retailers in the U.S.

- Activation requirements on U.S. networks for prepaid SIMs

Granted, if you're a company you can certainly acquire a lot of SIMs. A lot of questionable activity uses straw purchases, very similar to folks using smurfs to acquire pseudoephedrine in the 2000s.

calebio

hace 7 mesesdiscuss

> The 1994 paper (freely available at https://digital.library.unt.edu/ark:/67531/metadc1341727/m2/...) is actually about proper E2EE.

That paper is about PKI-based session setup for End-End which is the ancestor of SSL/TLS. It even mentions a CAE which is effectively a CA and it does a synchronous handshake to establish a symmetric key. It's very clearly about transport layer security from end to end.

It's not about User-User E2EE (akin to Signal) and shares very little other than that data is encrypted from point A to point B.

calebio

hace 7 mesesdiscuss

It wasn't coined, it was reused. It historically meant things that were encrypted from the client to the server, e.g. SSH, SSL, TLS, etc.

RFC 4949 (Internet Security Glossary, Version 2) from 2007: https://datatracker.ietf.org/doc/html/rfc4949

     $ end-to-end encryption
      (I) Continuous protection of data that flows between two points in
      a network, effected by encrypting data when it leaves its source,
      keeping it encrypted while it passes through any intermediate
      computers (such as routers), and decrypting it only when it
      arrives at the intended final destination. (See: wiretapping.
      Compare: link encryption.)

      Examples: A few are BLACKER, CANEWARE, IPLI, IPsec, PLI, SDNS,
      SILS, SSH, SSL, TLS.

      Tutorial: When two points are separated by multiple communication
      links that are connected by one or more intermediate relays, end-
      to-end encryption enables the source and destination systems to
      protect their communications without depending on the intermediate
      systems to provide the protection.

There's a bunch of older references as well. Since SSL/TLS wasn't really adopted by a lot of services until 2008+ usages of it are mainly in papers, old forum posts, etc. I saw it used and was discussing it back in the day on IRC with folks who were way more knowledgeable than me on this topic and had been in the trenches for a while :D

calebio

hace 7 mesesdiscuss

I'll take the hit on the loose phrasing regarding the SSL paper "outlining plans". That was a poor description of mine of an analysis paper and wasn't a good example of the point I was trying to make. However, you are focusing on the trees and missing the forest. The citations you analyzed actually prove the semantic shift I am describing, specifically the MITRE one.

You quoted the MITRE paper (or the older paper it references) defining end-to-end encryption as:

> "data being enciphered at the source and remaining unintelligible until it deciphered at its final destination."

This is the exact crux of the disagreement. In classic Client-Server architecture, the Server was the "final destination". The application processing the data lived on the server. Therefore, by the definition you just quoted, SSL/TLS from Client to Server was "End-to-End Encryption" because the network (routers/ISPs) could not decipher it.

The "modern" definition (post-Signal/WhatsApp) effectively redefined "final destination" to mean "another human user," relegating the Service Provider to a mere hop in the middle. That is a massive semantic shift.

re Saltzer's "End-to-End Arguments": The paper argues that functions (like reliability or encryption) should be moved from the lower network layers (links) to the "ends" (hosts/applications). SSL/TLS is the literal implementation of this argument: moving encryption out of the network links (Link Encryption) and into the application endpoints (Host-to-Host).

The term "End-to-End" in networking *has* historically meant Host-to-Host (Transport Layer), whereas the modern messaging usage means User-to-User. That is why a lot of folks from that era (and the RFCs) called SSL "End-to-End encryption" because relative to the network, it is.

---

RFC 4949 from 2007 (Internet Security Glossary) is quite explicit on this: https://datatracker.ietf.org/doc/html/rfc4949

> $ end-to-end encryption

> (I) Continuous protection of data that flows between two points in

> a network, effected by encrypting data when it leaves its source,

> keeping it encrypted while it passes through any intermediate

> computers (such as routers), and decrypting it only when it

> arrives at the intended final destination. (See: wiretapping. Compare: link encryption.)

>

> Examples: A few are BLACKER, CANEWARE, IPLI, IPsec, PLI, SDNS, SILS, SSH, *SSL, TLS*.

>

> Tutorial: When two points are separated by multiple communication

> links that are connected by one or more intermediate relays, end-

> to-end encryption enables the source and destination systems to

> protect their communications without depending on the intermediate

> systems to provide the protection.

---

RFC 1455 from 1993 (32 years ago) also uses the term in the IP/Host context: https://pike.lysator.liu.se/docs/ietf/rfc/14/rfc1455.xml

> At this time all Internet Protocol (IP) packets must have most of their header information, including the "from" and "to" addresses, in the clear. This is required for routers to properly handle the traffic even if a higher level protocol fully encrypts all bytes in the packet after the IP header. This renders even *end-to-end encrypted* IP packets subject to traffic analysis if the data stream can be observed.

---

Regarding your claim that "no one really used the E2EE term before it got the current meaning," the IETF standards for the internet (albeit an informational RFC and not a standards RFC) explicitly list SSL and TLS as examples of End-to-End encryption. The definition of "End" has simply shifted from the Machine to the User.

calebio

hace 7 mesesdiscuss

> No, before that it was simply not a term, except in some obscure radio protocol

> no one really used the E2EE term before it got the current meaning

It most certainly was a term and no it wasn't simply limited to "some obscure radio protocol".

1994: https://ieeexplore.ieee.org/abstract/document/363791

1984: https://dl.acm.org/doi/pdf/10.1145/357401.357402

1978: https://apps.dtic.mil/sti/tr/pdf/ADA059221.pdf

> Some homemade encryption added on top of TLS is very unlikely to increase the security of the system

"Some homemade encryption" is not what I was suggesting at all. E.g. encrypted-at-the-source (client side) AWS files are still sent over TLS as an encrypted blob within an encrypted blob but remain encrypted past the TLS boundary.

comments