Live data from Hacker News

Proposal: AI Content Disclosure Header

ietf.org

31–40 of 50 posts

Re: Proposal: AI Content Disclosure Header

#31

This seems like a (potential) solution looking for a nail-shaped problem. Yes, there is a huge problem with AI content flooding the field, and being able to identify/exclude it would be nice (for a variety of purposes) However, the issue isn't that content was "AI generated"; as long as the content is correct , and is what the user was looking for, they don't really care. The issue is content that was generated en-ma…

It says in the first paragraph it’s for crawlers and bots. How many humans are inspecting the headers of every page they casually browse? An immediate problem that could potentially be addressed by this is the “AI training on AI content” loop.

Re: Proposal: AI Content Disclosure Header

#32

This seems like a (potential) solution looking for a nail-shaped problem. Yes, there is a huge problem with AI content flooding the field, and being able to identify/exclude it would be nice (for a variety of purposes) However, the issue isn't that content was "AI generated"; as long as the content is correct , and is what the user was looking for, they don't really care. The issue is content that was generated en-ma…

It says in the first paragraph it’s for crawlers and bots. How many humans are inspecting the headers of every page they casually browse? An immediate problem that could potentially be addressed by this is the “AI training on AI content” loop.

I believe this is why Google did SynthID https://deepmind.google/science/synthid/

Re: Proposal: AI Content Disclosure Header

#33

Maybe we should avoid training AI with AI-generated content: that's a use case I would defend. Still I believe MIME would be the right place to say something about the Media, rather than the Transport protocol. On a lighter note: we should consider second order consequences. The EU commission will demand its own EU-AI-Disclosure header be send to EU citizens, and will require consent from the user before showing him…

It depends but for example if I wanted to train a LoRa that outputs a certain art style from a specific model, I have no issue with this being done. Its not like you are making a model from scratch.

Re: Proposal: AI Content Disclosure Header

#34

This seems like a (potential) solution looking for a nail-shaped problem. Yes, there is a huge problem with AI content flooding the field, and being able to identify/exclude it would be nice (for a variety of purposes) However, the issue isn't that content was "AI generated"; as long as the content is correct , and is what the user was looking for, they don't really care. The issue is content that was generated en-ma…

It says in the first paragraph it’s for crawlers and bots. How many humans are inspecting the headers of every page they casually browse? An immediate problem that could potentially be addressed by this is the “AI training on AI content” loop.

How many of the makers of these trash SEO sites are going to voluntarily identify their content as AI generated?

Re: Proposal: AI Content Disclosure Header

#35

Earlier quoted context omitted.

It says in the first paragraph it’s for crawlers and bots. How many humans are inspecting the headers of every page they casually browse? An immediate problem that could potentially be addressed by this is the “AI training on AI content” loop.

How many of the makers of these trash SEO sites are going to voluntarily identify their content as AI generated?

Moreover, I find it ironic that website owners will gracefully give AI companies the power to identify what is "good" data and what is not. I mean, why would I do the work for them and identify my data as AI, so that they would ignore it ? "yes please, take all my work, this is quality content, train on it, it's free !" that's what it sounds like

Re: Proposal: AI Content Disclosure Header

#36

This seems like a (potential) solution looking for a nail-shaped problem. Yes, there is a huge problem with AI content flooding the field, and being able to identify/exclude it would be nice (for a variety of purposes) However, the issue isn't that content was "AI generated"; as long as the content is correct , and is what the user was looking for, they don't really care. The issue is content that was generated en-ma…

It's the evil bit, but unironically.

Re: Proposal: AI Content Disclosure Header

#37
post #36

This seems like a (potential) solution looking for a nail-shaped problem. Yes, there is a huge problem with AI content flooding the field, and being able to identify/exclude it would be nice (for a variety of purposes) However, the issue isn't that content was "AI generated"; as long as the content is correct , and is what the user was looking for, they don't really care. The issue is content that was generated en-ma…

It's the evil bit, but unironically.

For today's lucky 10k:

https://www.ietf.org/rfc/rfc3514.txt

Note date published

Re: Proposal: AI Content Disclosure Header

#39
post #37
post #36

Earlier quoted context omitted.

It's the evil bit, but unironically.

For today's lucky 10k: https://www.ietf.org/rfc/rfc3514.txt Note date published

>Attack applications may use a suitable API to request that [the evil bit] be set. Systems that do not have other mechanisms MUST provide such an API; attack programs MUST use it.

Potential flaw: I'm concerned that attackers may be slow to update their malware to achieve compliance with this RFC. I suggest a transitional API: Intrusion detection systems respond to suspected-evil packets that have the evil bit set to 0 with a depreciation notice.

Re: Proposal: AI Content Disclosure Header

#40
post #37

Earlier quoted context omitted.

For today's lucky 10k: https://www.ietf.org/rfc/rfc3514.txt Note date published

>Attack applications may use a suitable API to request that [the evil bit] be set. Systems that do not have other mechanisms MUST provide such an API; attack programs MUST use it. Potential flaw: I'm concerned that attackers may be slow to update their malware to achieve compliance with this RFC. I suggest a transitional API: Intrusion detection systems respond to suspected-evil packets that have the evil bit set to…

deprecation notice
Post reply on HN