2 ms·
I understand that the .dev TLD is not supposed to support unencrypted HTTP (i.e. it is HTTPS only), browsers are supposed to know about this, and in fact the ma
by throwaway81523 5y ago
I understand that the .dev TLD is not supposed to support unencrypted HTTP (i.e. it is HTTPS only), browsers are supposed to know about this, and in fact the main ones supposedly do.
I wonder if we could also have a .restricted TLD that doesn't support javascript, the more invasive of these CSS hacks, transclusions of any sort except from the same domain, or cookies persisting longer than the browser session. That would make it a lot easier to have reasonable security assurance about pages with private contents, at the expense (or rather, the added benefit) of not being able to have blingy javascript effects on the page.
- zozbot234 5y agoThis kind of information is not appropriate for a TLD. If anything, it should be tacked on by extending the existing client-side-only URI fragment, i.e. the portion after a # delimiter. A number of mechanisms are available for such an extension to be broadly compatible with existing uses.
- throwaway81523 5y agoHmm ok, but maybe .dev should also have been handled that way? It seems too easy to mess up. Maybe the change should be at the protocol level, like rhttps (restricted https) instead of https. We do already have gemini but it is not really practical.