6 ms·

I see a lot of comments here about using some browser that will allow ME to see sites I want to see, but I did not see a lot about how do I protect my site or s

I see a lot of comments here about using some browser that will allow ME to see sites I want to see, but I did not see a lot about how do I protect my site or sites of clients from being subjected to this. Is there anything proactive that can be done? A set of checks almost like regression testing? I understand it can be a bit like virus builders using anti virus to test their next virus. But is there a set of best practices that could give you higher probability of not being blocked?

lucideer 11mo ago
> how do I protect my site or sites of clients from being subjected to this. Is there anything proactive that can be done? Some steps to prevent this happening to you: 1. Host only code you own & control on your own domain. Unless... 2. If you have a use-case for allowing arbitrary users to publish & host arbitrary code on a domain you own (or subdomains of), then ensure that domain is a separate dedicated one to the ones you use for your own owned code, that can't be confused with your own owned hosted content. 3. If you're allowing arbitrary members of the public to publish arbitrary code for preview/testing purposes on a domain you own - have the same separation in place for that domain as mentioned above. 4. If you have either of the above two use-cases, publish that separated domain on the Mozilla Public Suffix list https://publicsuffix.org/ https://publicsuffix.org/
- vintagedave 11mo ago
  That would protect your domains from being poisoned by arbitrary publishing, but wouldn't it risk all your users being affected by one user publishing?
  - lucideer 11mo ago
    Allowing user publishing is an inherent risk - these are good mitigations but nothing will ever be bulletproof. The main issue is protecting innocent users from themselves - that's a hard one to generalise solutions to & really depends on your publishing workflows. Beyond that, the last item (Public Suffix list) comes with some decent additional mitigations as an upside - the main one being that Firefox & Chrome both enable more restrictive cookie settings while browsing any domains listed in the public suffix list. --- All that said - the question asked in the comment at the top of the thread wasn't about protecting users from security risk, but protecting the domain from being flagged by Google. The above steps should at least do that pretty reliably, barring an actual legitimate hack occurring.
    - asimpleusecase 11mo ago
      Thank you for your thoughtful and helpful reply.
account42 11mo ago
> Is there anything proactive that can be done? Befriend a lawyer that will agree to send a letter to Google on your behalf in case it happens.

lucideer 11mo ago

> how do I protect my site or sites of clients from being subjected to this. Is there anything proactive that can be done? Some steps to prevent this happening to you: 1. Host only code you own & control on your own domain. Unless... 2. If you have a use-case for allowing arbitrary users to publish & host arbitrary code on a domain you own (or subdomains of), then ensure that domain is a separate dedicated one to the ones you use for your own owned code, that can't be confused with your own owned hosted content. 3. If you're allowing arbitrary members of the public to publish arbitrary code for preview/testing purposes on a domain you own - have the same separation in place for that domain as mentioned above. 4. If you have either of the above two use-cases, publish that separated domain on the Mozilla Public Suffix list https://publicsuffix.org/ https://publicsuffix.org/

vintagedave 11mo ago
That would protect your domains from being poisoned by arbitrary publishing, but wouldn't it risk all your users being affected by one user publishing?
- lucideer 11mo ago
  Allowing user publishing is an inherent risk - these are good mitigations but nothing will ever be bulletproof. The main issue is protecting innocent users from themselves - that's a hard one to generalise solutions to & really depends on your publishing workflows. Beyond that, the last item (Public Suffix list) comes with some decent additional mitigations as an upside - the main one being that Firefox & Chrome both enable more restrictive cookie settings while browsing any domains listed in the public suffix list. --- All that said - the question asked in the comment at the top of the thread wasn't about protecting users from security risk, but protecting the domain from being flagged by Google. The above steps should at least do that pretty reliably, barring an actual legitimate hack occurring.
  - asimpleusecase 11mo ago
    Thank you for your thoughtful and helpful reply.

account42 11mo ago

> Is there anything proactive that can be done? Befriend a lawyer that will agree to send a letter to Google on your behalf in case it happens.