jard

Definitely a battery-related issue. When I first got my Deck a year ago I actually had a very similar experience. Turns out the power regulator IC that controlled the voltage from the battery got itself fried, so not only did I get the burning and hissing but it just straight up refused to boot and charge.

If you want to you can try diagnosing the issue further… but yeah, RMA time. It’s so much easier.

I tested it on iOS Safari with my own hosted instance and it seems to be fine. Is macOS Safari different? Maybe that’d be a good bug to report.

Fair enough, it’s definitely not for everyone. It’s a great learning experience though!

In that case, Joplin and something like Syncthing + Git (so that you remain in control of your data) would fit your need, since in essence you’d just be securely and privately passing around all your notes/files over a decentralized network.

If you’re comfortable with self hosting, I recommend SilverBullet: it’s a Markdown-based knowledge management solution that runs as a PWA in any modern browser. It automatically syncs to a hosted SilverBullet server during use when you have an internet connection, and otherwise can run completely offline (provided that you use a browser that supports offline PWAs)

OP’s “evidence” is that Kagi internally uses Sentry.io (a FOSS crash report aggregation service for developers) to report crash logs, which they then use to assert that Kagi is aggregating personal data and sending that data to Sentry. The “proof” is that they used an Android tool that reports whether an APK contains specific Java classes whose fully qualified names match a “tracker” name filter (which, coincidentally, cherry-picks Sentry.io as a tracker), runs it on some completely irrelevant Android APK, and then concludes that because these classes are showing up with their cherry-picked filter, Sentry.io is a tracker, ergo Kagi is tracking personal data. Q.E.D.

In short, it’s complete nonsense. I did a thorough debunking of their methodology in a previous comment of mine. You can safely ignore anything they have to say.

You clearly don’t understand how this works, do you?

Let’s start from the beginning: Your suggested app, “classyshark3xodus”, notes that the database it uses is the concatenation of the existing exodus-privacy trackers, as well as an addendum list of 31 “additions”. Most importantly, this list comes from the repository linked here.

Let’s ignore, for a moment, that this clearly implies that the creator of this app lied about the database it uses (because it’s very clearly not some official “new” Exodus database, but a hodgepodge mashup made by some complete stranger on the Internet…) The repository for the addendum list states that the Sentry listing comes from the Exodus Tracker Investigation Program (ETIP). Thus, we expect that there should be a page on the ETIP for Sentry, and indeed there is one here.

We can see that the description for this tracker is… hold your breath… to report unhandled exceptions to an online service. It’s almost as if… that was the exact, entire, unmitigated stated purpose of the fucking software in the first place! Also note that the stated category is… again, hold your breath… crash reporting. Again, this is exactly the stated purpose of the SDK, which was advertised on their own site.

This means you already lied multiple times about the intended purpose of Sentry. Your own source states that Sentry is not an “analytics company”, but a “crash reporting” service. Again, this is what we have already clearly established by a very cursory, trivial look at the software itself. Oh, also, it’s also stated in the ETIP that Sentry is not even listed in Exodus as a tracker. Gee, I sure wonder why…?

I also had the displeasure of going through with downloading this app from F-droid and testing it on Fennec as you stated. As expected for the simplistic process of “does the fully qualified name of this class begin with this specific filter?” Sentry classes show up.

I know what I’m doing, so let’s dig into some of the classes. The vast majority of them are actually dummy classes that do not contain any fields or functions that mutate state. For example, io.sentry.UserFeedback:

package io.sentry;
import java.lang.String;

public final class UserFeedBack extends Object
{
/*
 * Field Definitions.
 */
/*
 * Declared Constructors
 */
    public final String toString() { ... }
}

The reason for this is that F-Droid runs ProGuard on compiled artifacts from source, which optimizes away unused Java bytecode. This means we can be sure that the APK we received only consists of the instructions actually used by the APK. An empty class file also means that it is a stateless class, and for the sake of OOP is effectively a no-op that can’t perform anything.

So with that being said, let’s dig straight into the io.sentry.protocol.User class. We should expect this to contain the most sensitive user information sent to this “analytics” company, such as email addresses, geo locations, and… uhh wait…

package io.sentry.protocol;
import java.lang.Object;

public final class User extends Object
{
/*
 * Field Definitions.
 */
/*
 * Declared Constructors
 */
  public User() { ... }
  public final boolean equal(Object) { ... }
  public final int hashCode() { ... }
}

It’s a dummy class! That means it can’t store anything about the user because it doesn’t do any of that in the first place, thus being optimized away by ProGuard. Oops.

So, how about io.sentry.protocol.Session?

package io.sentry;
import ...

public final class Session extends Object
{
/*
 * Field Definitions.
 */
    public String abnormalMechanism;
    public final String distinctId;
    public Double duration;
    public final String environment;
    public final AtomicInteger errorCount;
    public Boolean init;
    public final String ipAddress;
    public final String release;
    public Long sequence;
    public final UUID sessionId;
    public final Object sessionLock;
    public final Date started;
    public Session$State status;
    public Date timestamp;
    public String userAgent;
/*
 * Declared Constructors.
 */
    public Session(Session$State, Date, Date, int, String, UUID, Boolean, Long, Double, String, String, String, String, String) { ... }
    public final Session clone() { ... }
    public final volatile Object clone() throws CloneNotSupportedException { ... }
}

Finally, a class with actual state! We can see from here that a Sentry session can contain the following information:

• The user’s IP address. Pro tip – any time you connect to the Internet, your outmost IP address is always shared with any destination servers you connect to. This is in the design of the protocol.
• The ‘userAgent’. According to this line, the user agent is sent as the User-Agent header of the HTTP request to Sentry’s servers. This value is composed of the app’s chosen programming language and platform of choice of the user, along with the version of the Sentry SDK.
• The user environment. From these lines this is simply whether the user is operating in a production or development environment; e.g. the typical Fennec user will be running in a “production environment.” Standard stuff.
• Information related to the internal Sentry session, such as error counts, session length, error status, time the session started, etc. This information is intrinsically anonymous, since it’s tied to the operation of the application itself and not the user.

So what potentially personal information does Sentry “leak” in a session?

• The user IP address
• The platform of the user (for Fennec, it is always Android)
• … that’s it.

In other words… this is a typical crash log… containing the unhandled exception which caused the crash… that is then sent over to a server over the Internet via a specific user’s Internet connection (leaking an IP by necessity of the protocol). In other words… this is a crash reporting service. 🤦

As war said, you don’t know what Sentry does. Actually, you don’t understand how any of this works. This is a privacy community first and foremost, but I also expect that FOSS “enthusiasts” such as yourself actually understand how to work with FOSS.

Anonymity is not the same as privacy, because the latter fundamentally entails a measure of trust between two parties over the control of personally identifying information. Note that this is contingent on whether that personal information is exchanged.

In the situation you described, privacy is irrelevant in either case, whether you access a SearXNG instance with a VPN/Tor or use a pseudonym and Monero payments to access Kagi, because no personal information was exchanged in the first place.

The “privacy” in both situations then becomes how difficult it is for a bad actor to deanonymize you, which comes down to whether you can trust that the VPN service you’re using isn’t logging your traffic and the email service your pseudonym is on won’t just give up your data… or whether Tor isn’t being actively deanonymized via malicious exit nodes controlled by certain three-letter government agencies. This isn’t a fault on either search engine, IMO.

we can’t be sure what code are they exactly running on the server side

The same can be said about the hundred random SearXNG instances floating around on the Internet. How do you know that some of those aren’t running custom binaries that are then linking your IP to your search queries and sending them off?

The only true solution is to self host, but the majority of people are looking for a quick and easy Google/DDG replacement, not to completely overhaul their digital life.

The non-exhaustive list of Python, Swift, Java and native bindings for the Sentry SDK are all FOSS by your own criterion, so I’m not sure where this whole FOSS diatribe is coming from.

Again, can you send a direct link to a credible source (read: not a remark to “look it up myself”) that presents the evidence on exactly how Sentry aggregates and collects personal data? Your criticism about corporate privacy policies boiling down to a “just trust us bro” mentality can be applied to your own claims and chain of comments: without any evidence I’m forced to take your assertions at face value and “just trust you bro.”

Searching for Sentry with your supplied source gives nothing helpful, in fact Exodus doesn’t even list Sentry as a tracker here. I’m sure a “well known and notorious” tracker should be listed as such.

So again, citation needed. Link evidence of these claims.

From my understanding, Kagi counts searches against accounts based on how many times that account has accessed the search endpoint. That is, multiple repeated searches (over a period of time) are treated as unique searches.

According to them, searches are cached for 2 minutes, and next page results are also counted as a unique search.

“Anonymous logs are shared with Sentry when bugs, crashes, or warnings occur for debugging purposes.”

It is quite a leap in logic — a non sequitur, even — to go from “debug crash logs sent to a crash reporting service” to “your personal information is being shared with third parties,” especially since Sentry themselves advise that their own users (developers) should not send personal information to them.

Please give the evidence detailing what personally identifying information Kagi collects and how they send it to Sentry, since you clearly know how things work internally in there.

They do share data with a notorious 3rd party tracking company.

Care to give any details?

Yep, for some reason Valve and the incessant Steam fanboys insist that mobile-based Steam Guard is absolutely perfect and anything like U2F just makes things more insecure… somehow.

Fortunately, Bitwarden at least implemented Steam’s own TOTP algorithm. With a very user unfriendly process you can grab the authenticator key Steam gives you via the third party Steam Guard desktop client, insert it into Bitwarden, and then it’ll happily generates the right verification codes for you.

I use Bitwarden TOTP because my Bitwarden account is already secured with a Yubikey as a second factor. It’s the best solution I have for services that only provide TOTP and not FIDO U2F (I would use the Yubikey directly otherwise.)

Same story here. I self hosted my email with a Linode for a year and a half and it fucking sucked. Gmail almost always filters inbound email from what they deem as untrustworthy IP addresses (which is pretty much any mail server other than the big players), and even if you never plan on mailing Gmail addresses your server’s IP will show up on some “critical spam” blacklist somewhere simply because you’re running a mail server, which basically spells doom for mail deliverability.

You also need to diligently harden your mail server because bots indiscriminately try to find loopholes in mail server configs all the time, and once they do they start spamming their poor victims through your server. It’s a fool’s errand that varies wildly based on what distro you installed, which mail/postfix/dovecot/fail2bam/dkim/spf etc configuration you have, and a lot of the time the information doesn’t actually exist on the Internet so you have to figure it all out yourself.

Ever since I switched to Tutanota + redirection with my domain I’ve never had any of these issues, and I’m never going to look back. It’s unfortunate, but the days of self hosting mail servers are over. It’s simply not worth the struggle and it just becomes an uphill battle in the end.

Not really…? They’re probably trying to see how others integrated gym equipment into a (WFH) office space. That’s a far cry from being an odd inquiry.

Army sergeant engages with a sniper shaolin monk in a brutal battle to the death. Multiple times in a row.

I can’t hold others who shill for Google in good faith, not after what the business has been doing for years, and especially recently. They’re several orders of magnitude worse than Apple at this point.

Blind faith in a monopoly who controls the ads on almost half of all Internet websites, 70% of the browser market (and the phone OS market for that matter), basically the entirety of online video sharing, etc… is precisely why Google is able to force anti-web bullshit like attestation-based DRM. And there’s nothing we can do about it; their engineers doubled down on WEI and liken us to criminals.

Intel isn’t buying SiFive. That deal fell through almost 2 years ago.