Earlier quoted context omitted.
Also YouTube.com serves a lot of scam advertisements. They should block that too.
I think google is crumbling under the weight of their size. They are no longer able to process the requested commercials with due diligence.
Google flags Immich sites as dangerous
341–350 of 713 posts
Re: Google flags Immich sites as dangerous
#342Re: Google flags Immich sites as dangerous
#343I 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 p…
> 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…
Re: Google flags Immich sites as dangerous
#344Earlier quoted context omitted.
Looking through some of the links in this post, I there are actually two separate issues here: 1. Immich hosts user content on their domain. And should thus be on the public suffic list. 2. When users host an open source self hosted project like immich, jellyfin, etc. on their own domain it gets flagged as phishing because it looks an awful lot like the publicly hosted version, but it's on a different domain, and pos…
I don't think the Internet should be run by being on special lists (other than like, a globally run registry of domain names)... I get that SPAM, etc., are an issue, but, like f* google-chrome, I want to browse the web, not some carefully curated list of sites some giant tech company has chosen. A) you shouldn't be using google-chrome at all B) Firefox should definitely not be using that list either C) if you are goi…
I've coined the phrase "Postel decentralization" to refer to things where people expect there to be some distributed consensus mechanism but it turned out that the design of the internet was to email Jon Postel (https://en.wikipedia.org/wiki/Jon_Postel) to get your name on a list. e.g. how IANA was originally created.
Re: Google flags Immich sites as dangerous
#345Earlier quoted context omitted.
How else am I going to make a game in the browser that be controlled with a controller?
Every decent host OS already has a dedicated driver stack to provide game controller input to applications in a useful manner. Why the heck would you ship a reimplementation of that in JS in a website?
Re: Google flags Immich sites as dangerous
#346Earlier quoted context omitted.
It doesn’t seem like email scanning is necessary to explain this. It appears that simply having a “bad” subdomain can trigger this. Obviously this heuristic isn’t working well, but you can see the naive logic of it: anything with the subdomain “apple” might be trying to impersonate Apple, so let’s flag it. This has happened to me on internal domains on my home network that I've exposed to no one. This also has been r…
In my case though, the Google Search Console explicitly listed the exact URL for a newly created shared folder as the cause. https://photos.example.com/albums/xxxxxxxx-xxxx-xxxx-xxxx-xx... That's not going to be gleaned from a CT log or guessed randomly. The URL was only transmitted once to one person via e-mail. The sending was done via MXRoute and the recipient was using GMail (legacy Workspace). The only possible…
Re: Google flags Immich sites as dangerous
#347Happened to me last week. One morning we wake up and the whole company website does not work. Not advice with some time to fix any possible problem, just blocked. We gave very bad image to our clients and users, and had to give explanations of a false positive from google detection. The culprit, according to google search console, was a double redirect on our web email domain (/ -> inbox -> login). After just moving…
I'm beginning to seriously think we need a new internet, another protocol, other browsers just to break up the insane monopolies that has been formed, because the way things are going soon all discourse will be censored, and competitors will be blocked soon. We need something that's good for small and medium businesses again, local news and get an actual marketplace going - you know what the internet actually promise…
Re: Google flags Immich sites as dangerous
#348Earlier quoted context omitted.
I think google is crumbling under the weight of their size. They are no longer able to process the requested commercials with due diligence.
I see the same scam/deepfake ad(s) pretty much persistently. Maybe they actually differ slightly (they are AI gen mostly), but it's pretty obvious what they are, and I'm sure they get flagged a lot. They just need to introduce a basic deposit to post ads, and you lose it if you put up a scam ad. Would soon pay for the staff needed to police it, and prevent scammers from bypassing admin by trivially creating new accou…
Re: Google flags Immich sites as dangerous
#349Be sure to see the team's whole list of Cursed Knowledge. https://immich.app/cursed-knowledge
I've now read the entire Cursed Knowledge list & - while I found some of them to be invaluable insights & absolutely love the idea of projects maintaining a public list of this nature to educate - there are quite a few red flags in this particular list.
Before mentioning them: some excellent & valuable, genuinely cursed items: Postgres NOTIFY (albeit adapter-specific), npm scripts, bcrypt string lengths & especially the horrifically cursed Cloudflare fetch: all great knowledge. But...
> Secure contexts are cursed
> GPS sharing on mobile is cursed
These are extremely sane security feature. Do we think keeping users secure is cursed? It honestly seems crazy to me for them to have published these items in the list with a straight face.
> PostgreSQL parameters are cursed
Wherein their definition of "cursed" is that PG doesn't support running SQL queries with more than 65535 separate parameters! It seems to me that any sane engineer would expect the limit to be lower than that. The suggestion that making an SQL query with that many parameters is normal seems problematic.
> JavaScript Date objects are cursed
Javascript is zero-indexed by convention. This one's not a huge red flag but it is pretty funny for a programmer to find this problematic.
> Carriage returns in bash scripts are cursed
Non-default local git settings can break your local git repo. This isn't anything to do with bash & everyone knows git has footguns.
Re: Google flags Immich sites as dangerous
#350Earlier quoted context omitted.
> 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…
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?
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.