Earlier quoted context omitted.
A website where a user can upload "active code". The definition of "active code" is broad & sometimes debatable - e.g. do old MySpace websites count - but broadly speaking the best way of thinking about it is in terms of threat model, & the main two there are: - credential leakage - phishing The first is fairly narrow & pertains to uploading server side code or client javascript. If Alice hosts a login page on alice.…
> what Immich is doing here is extremely dangerous You fully misunderstand what content is hosted on these sites. It's only builds from internal branches by the core team, there is no path for "external user" content to land on this domain.
Google flags Immich sites as dangerous
591–600 of 713 posts
Re: Google flags Immich sites as dangerous
#592We really need an internet Bill of Rights. Google has too much power to delete your company from existence with no due process or recourse. If any company controls some (high) percentage of a particular market, say web browsers, search, or e-commerce, or social media, the public's equal access should start to look more like a right and less like an at-will contract. 30 years ago, if a shop had a falling out with the…
Force interoperability. In 2009 I could run Pidgin and load messages from AIM, FB Messages, Yahoo... Where did that go? I suspect the EU will be the first region to push the big tech companies on this.
We do monthly updates on the status of the project that we call State of the Bird and they can be found here https://discourse.imfreedom.org/tag/state-of-the-bird.
Re: Google flags Immich sites as dangerous
#593Re: Google flags Immich sites as dangerous
#594Earlier quoted context omitted.
Was Pidgin TOS-compliant back in the day? I'm a young whippersnapper, so I don't have experience with it myself.
Well it did have to change its name from GAIM to Pidgin at some point because it infringed on "AIM" by AOL. And whether or not Pidgin was fully "TOS-compliant" (which it might have been depending on the service we'd be looking at) is not as relevant as whether these terms would have been actually legally enforceable or not.
Re: Google flags Immich sites as dangerous
#595Earlier quoted context omitted.
A part of the issue is IMO that browsers have become ridiculously bloated everything-programs. You could take about 90% of that out and into dedicated tools and end up with something vastly saner and safer and not a lot less capable for all practical purposes. Instead, we collectively are OK with frosting this atrocious layer cake that is today's web with multiple flavors of security measures of sometimes questionabl…
> A part of the issue is IMO that browsers have become ridiculously bloated everything-programs. I don't see how that solves the issue that PSL tries to fix. I was a script kiddy hosting neopets phishing pages on free cpanel servers from .ripway.com back in 2007. Browsers were way less capable then.
Try 90s! We had to fight off ActiveX Plugins left and right in the good olde Internet Explorer! Yarr! ;-)
Re: Google flags Immich sites as dangerous
#596Just because it's your website, and you're not a bad agent doesn't prove that no part of the site is under the control of a bad agent, and that your site isn't accidentally hosting something malicious somewhere, or have some UI that is exploitable for cross-site scripting or whatever.
Re: Google flags Immich sites as dangerous
#597Earlier quoted context omitted.
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…
Not quite. Presumably the recipient clicked the link, at which point their browser knows it and, depending on browser and settings, may submit it to Google to check if it's "safe": https://support.google.com/chrome/answer/9890866#zippy=%2Cen...
I've read almost everything linked in this post and on Reddit and, with what you pointed out considered, I'd say the most likely thing that got my domain flagged is having a redirect to a default styled login page.
The thing that really frustrates me if that's the case is that it has a large impact on non-customized self-hosted services and Google makes no effort to avoid the false positives. Something as simple as guidance for self-hosted apps to have a custom login screen to differentiate from each other would make a huge difference.
Of course, it's beneficial to Google if they can make self-hosting as difficult as possible, so there's no incentive to fix things like this.
Re: Google flags Immich sites as dangerous
#598Earlier quoted context omitted.
And now your Gmail account has been deleted as well as any other accounts you had with Google
That's okay, you have backup of your data, and you don't really depend on your Gmail account for anything important.
Re: Google flags Immich sites as dangerous
#599Earlier quoted context omitted.
And now your Gmail account has been deleted as well as any other accounts you had with Google
So what? Why would you want to continue to use the services of a company you had to sue? That’s kind of a “burning the bridges” moment.
Re: Google flags Immich sites as dangerous
#600Navigating to https://main.preview.internal.immich.cloud, I'm right away informed by the browser that the connection is not secure due to an issue with the certificate. The problem is that it has the following CN (common name): main.preview.internal.immich.build. The list of alternative names also contains that same domain name. It does not match the site: the certificate's TLD .build is different from the site's .cloud!
I don't see the same problem on external sites like tiles.immich.cloud. That has a CN=immich.cloud with tiles.immich.cloud as an alternative.