[Webkit-unassigned] [Bug 237632] New: Consider disabling pre-fetching for .new domains

[bugzilla-daemon at webkit.org]

https://bugs.webkit.org/show_bug.cgi?id=237632

            Bug ID: 237632
           Summary: Consider disabling pre-fetching for .new domains
           Product: WebKit
           Version: Safari 15
          Hardware: All
                OS: All
            Status: NEW
          Severity: Normal
          Priority: P2
         Component: WebKit API
          Assignee: webkit-unassigned at lists.webkit.org
          Reporter: 06.secants-easels at icloud.com

Google has set up the .new TLD to allow companies to create quick web shortcuts to create new content. For example visiting https://presentation.new will create a new Google Slides presentation or https://blog.new will create a new WordPress.com blog account/site.

Technically these URIs break the HTTP spec in that GET requests are supposed to be [safe](https://developer.mozilla.org/en-US/docs/Glossary/Safe/HTTP) and not alter the state of the server but I was wondering if WebKit should be pragmatic about this and disable link pre-fetching for sites in the .new TLD (if it's even feasible to decide on a per-domain or per-TLD basis).

The prompt for this is that I just found several untitled documents in my work Google Drive that were created by Safari pre-fetching https://forms.new, https://sheets.new and https://slides.new.

Realistically, the Google apps teams should be detecting these requests and automatically deleting the "drafts" that get created by pre-fetching but given the purpose of the .new TLD and the side-effects from visiting a .new domain I thought I'd raise the question.

P.S. I wasn't sure how to categorise this bug so I modelled it off bug 42501

-- 
You are receiving this mail because:
You are the assignee for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.webkit.org/pipermail/webkit-unassigned/attachments/20220309/f8af4417/attachment.htm>