There are already so many different ways that organizations can find out all sorts of information about individual users, as others have noted (social media interactions, mobile location/GPS data, call/text history, interactions with specific sites, etc), that there probably isn't much incentive for many providers to harvest data beyond what is needed for troubleshooting and capacity planning.  Plus, gathering more data - potentially down to the level packet payload - is not an easy problem to solve (read: expensive) and doesn't scale well at all. 100G links are very common today, and 400G is becoming so.  I doubt that many infrastructure providers would be able to justify the major investments in extra infrastructure to support this, for a revenue stream that likely wouldn't match that investment, which would make such an investment a loss-leader.

Content providers - particularly social media platforms - have a somewhat different business model, but those providers already have many different ways to harvest and sell large troves of user data.

Thank you
jms

On Tue, May 16, 2023 at 3:44 PM Matthew Petach <mpetach@netflight.com> wrote:


On Tue, May 16, 2023 at 1:10 AM Jeroen Massar <jeroen@massar.ch> wrote:


> On 16 May 2023, at 06:46, Matthew Petach <mpetach@netflight.com> wrote:
> [..]
> I admit, I'm perhaps a little behind on the latest netflow whiz-bangs,
> but I've never seen a netflow record type that included HTTP cookies
> or PCAP data before.

Take your pick from the "latest" ~2009 IPFIX Information Elements:

https://www.iana.org/assignments/ipfix/ipfix.xhtml

One can stuff almost anything in there.

Now if one should, and if one is allowed to.....

Wow.

Thank you, Jeroen, I was indeed a bit out of date. 
Thank you for the pointer!

(For those in the same boat as I, here's the relevant portion that clearly points out that yes, you can export the entire packet if you so desire):

313ipHeaderPacketSectionoctetArraydefaultcurrent

This Information Element carries a series of n octets from the IP header of a sampled packet, starting sectionOffset octets into the IP header.

However, if no sectionOffset field corresponding to this Information Element is present, then a sectionOffset of zero applies, and the octets MUST be from the start of the IP header.

With sufficient length, this element also reports octets from the IP payload. However, full packet capture of arbitrary packet streams is explicitly out of scope per the Security Considerations sections of [RFC5477] and [RFC2804].



 Thanks!

Matt
(still learning after all these years.   ^_^ )