Firedragon garuda search problem

[appu]

I think Garuda Whoogle search is slower than google , some times it takes more time (6-8 sec) to search a keyword . i have started using firedragon instead of firefox firedragon-vs-firefox , every thing works good ... it eat less ram than firefox ,

but the problem happened with garuda search.. and sometimes it shows that refuse cookie error "(but i use default cookie configuration of firedragon)

what that mean and what to do to fix this??

╭─sshanku@shanku in ~ 
╰─λ garuda-inxi
System:
Kernel: 5.16.10-zen1-1-zen x86_64 bits: 64 compiler: gcc v: 11.2.0
parameters: BOOT_IMAGE=/@/boot/vmlinuz-linux-zen
root=UUID=1c542029-1def-474b-9a7b-a27875482987 rw rootflags=subvol=@
quiet splash rd.udev.log_priority=3 vt.global_cursor_default=0
systemd.unified_cgroup_hierarchy=1
resume=UUID=388ac47a-43b6-4dde-80f6-a8b43e1c5164 loglevel=3
Desktop: KDE Plasma 5.24.1 tk: Qt 5.15.2 info: latte-dock wm: kwin_x11
vt: 1 dm: SDDM Distro: Garuda Linux base: Arch Linux
Machine:
Type: Desktop System: Gigabyte product: H110M-S2 v: N/A
serial: <superuser required>
Mobo: Gigabyte model: H110M-S2-CF v: x.x serial: <superuser required>
UEFI-[Legacy]: American Megatrends v: F21 date: 06/09/2017
CPU:
Info: model: Intel Core i3-6100 bits: 64 type: MT MCP arch: Skylake-S
family: 6 model-id: 0x5E (94) stepping: 3 microcode: 0xEC
Topology: cpus: 1x cores: 2 tpc: 2 threads: 4 smt: enabled cache:
L1: 128 KiB desc: d-2x32 KiB; i-2x32 KiB L2: 512 KiB desc: 2x256 KiB
L3: 3 MiB desc: 1x3 MiB
Speed (MHz): avg: 800 min/max: 800/3700 scaling: driver: intel_pstate
governor: powersave cores: 1: 800 2: 800 3: 800 4: 800 bogomips: 29598
Flags: avx avx2 ht lm nx pae sse sse2 sse3 sse4_1 sse4_2 ssse3 vmx
Vulnerabilities:
Type: itlb_multihit status: KVM: VMX disabled
Type: l1tf
mitigation: PTE Inversion; VMX: conditional cache flushes, SMT vulnerable
Type: mds mitigation: Clear CPU buffers; SMT vulnerable
Type: meltdown mitigation: PTI
Type: spec_store_bypass
mitigation: Speculative Store Bypass disabled via prctl
Type: spectre_v1
mitigation: usercopy/swapgs barriers and __user pointer sanitization
Type: spectre_v2 mitigation: Full generic retpoline, IBPB: conditional,
IBRS_FW, STIBP: conditional, RSB filling
Type: srbds mitigation: Microcode
Type: tsx_async_abort status: Not affected
Graphics:
Device-1: Intel HD Graphics 530 vendor: Gigabyte driver: i915 v: kernel
bus-ID: 00:02.0 chip-ID: 8086:1912 class-ID: 0300
Device-2: NVIDIA GT218 [GeForce G210] driver: nouveau v: kernel
bus-ID: 01:00.0 chip-ID: 10de:0a60 class-ID: 0300
Display: x11 server: X.Org 1.21.1.3 compositor: kwin_x11 driver:
loaded: modesetting display-ID: :0 screens: 1
Screen-1: 0 s-res: 1366x768 s-dpi: 96 s-size: 361x203mm (14.2x8.0")
s-diag: 414mm (16.3")
Monitor-1: DP-1 res: 1366x768 hz: 60 dpi: 85 size: 410x230mm (16.1x9.1")
diag: 470mm (18.5")
OpenGL: renderer: Mesa Intel HD Graphics 530 (SKL GT2) v: 4.6 Mesa 21.3.6
direct render: Yes
Audio:
Device-1: Intel 100 Series/C230 Series Family HD Audio vendor: Gigabyte
driver: snd_hda_intel v: kernel bus-ID: 00:1f.3 chip-ID: 8086:a170
class-ID: 0403
Device-2: NVIDIA High Definition Audio driver: snd_hda_intel v: kernel
bus-ID: 01:00.1 chip-ID: 10de:0be3 class-ID: 0403
Sound Server-1: ALSA v: k5.16.10-zen1-1-zen running: yes
Sound Server-2: sndio v: N/A running: no
Sound Server-3: PulseAudio v: 15.0 running: yes
Sound Server-4: PipeWire v: 0.3.47 running: yes
Network:
Device-1: Realtek RTL8111/8168/8411 PCI Express Gigabit Ethernet
vendor: Gigabyte driver: r8169 v: kernel port: d000 bus-ID: 02:00.0
chip-ID: 10ec:8168 class-ID: 0200
IF: enp2s0 state: up speed: 1000 Mbps duplex: full mac: <filter>
Drives:
Local Storage: total: 1.36 TiB used: 91.53 GiB (6.6%)
SMART Message: Unable to run smartctl. Root privileges required.
ID-1: /dev/sda maj-min: 8:0 vendor: Western Digital
model: WD10EZEX-60WN4A0 size: 931.51 GiB block-size: physical: 4096 B
logical: 512 B speed: 6.0 Gb/s type: HDD rpm: 7200 serial: <filter>
rev: 1A01 scheme: MBR
ID-2: /dev/sdb maj-min: 8:16 vendor: Seagate model: ST3500413AS
size: 465.76 GiB block-size: physical: 512 B logical: 512 B speed: 6.0 Gb/s
type: HDD rpm: 7200 serial: <filter> rev: JC4B scheme: MBR
Partition:
ID-1: / raw-size: 127.93 GiB size: 127.93 GiB (100.00%)
used: 52.33 GiB (40.9%) fs: btrfs dev: /dev/sdb3 maj-min: 8:19
ID-2: /home raw-size: 147.46 GiB size: 147.46 GiB (100.00%)
used: 39.2 GiB (26.6%) fs: btrfs dev: /dev/sdb4 maj-min: 8:20
ID-3: /var/log raw-size: 127.93 GiB size: 127.93 GiB (100.00%)
used: 52.33 GiB (40.9%) fs: btrfs dev: /dev/sdb3 maj-min: 8:19
ID-4: /var/tmp raw-size: 127.93 GiB size: 127.93 GiB (100.00%)
used: 52.33 GiB (40.9%) fs: btrfs dev: /dev/sdb3 maj-min: 8:19
Swap:
Kernel: swappiness: 133 (default 60) cache-pressure: 100 (default)
ID-1: swap-1 type: partition size: 3.91 GiB used: 0 KiB (0.0%)
priority: -2 dev: /dev/sdb2 maj-min: 8:18
ID-2: swap-2 type: zram size: 7.65 GiB used: 176.5 MiB (2.3%)
priority: 100 dev: /dev/zram0
Sensors:
System Temperatures: cpu: 29.8 C mobo: 27.8 C gpu: nouveau temp: 39.0 C
Fan Speeds (RPM): N/A
Info:
Processes: 264 Uptime: 1h 14m wakeups: 0 Memory: 7.65 GiB
used: 5.31 GiB (69.4%) Init: systemd v: 250 tool: systemctl Compilers:
gcc: 11.2.0 clang: 13.0.1 Packages: pacman: 1651 lib: 377 Shell: fish
v: 3.3.1 default: Bash v: 5.1.16 running-in: konsole inxi: 3.3.12
Garuda (2.5.5-1):
System install date:     2021-12-28
Last full system update: 2022-02-20
Is partially upgraded:   No
Relevant software:       NetworkManager
Windows dual boot:       <superuser required>
Snapshots:               Snapper
Failed units:            bluetooth-autoconnect.service shadow.service
type or paste code here

and after reload the search whoogle turns into white theme

[FGD]

This is because it is a proxy to Google and Whoogle/Garuda-Search's servers are not (yet ) as fast as Google's, so it will be slower depending on how many people are using the search at the same time. This also explains why sometimes you have to click TRY AGAIN or wait and retry.

There is a topic on the forum from a few weeks back which explains exactly that.

[appu]

ya, this is ok
but , how to manage that cookie problem?
should i change default privacy settings?

[FGD]

I don't see any cookie error in your screenshots.
The second screenshot is not cookie related and happens to me to once in a while depening on the number of people using the search.

[BluishHumility]

@appu

I think Garuda Whoogle search is slower than google , some times it takes more time (6-8 sec) to search a keyword

This is true, it is slower. The reason it takes longer is because it is essentially adding a process on top of the Google search you are doing.

As FGD mentioned, Whoogle is a search proxy for Google, designed to filter out ads or sponsored links, and change links from AMP/Google-related redirects into plain links that just take you to the website without additional funny business. It is not it’s own search engine.

The Whoogle you are using is Garuda’s public instance, which means when you send out your Whoogle query it first gets sent to Garuda’s server, then to Google, then Google returns the results to the Garuda server where the Whoogle instance filters out all the junk, and finally it gets passed back to you. So it does take a little longer than just using Google without the proxy filter.

If you enjoy using Whoogle but would prefer a more performant instance of it, you can consider deploying your own. There are tons of ways to deploy Whoogle: GitHub - benbusby/whoogle-search: A self-hosted, ad-free, privacy-respecting metasearch engine

As for this:

@appu

but the problem happened with garuda search… and sometimes it shows that refuse cookie error

I am not certain (maybe someone can jump in if I’m off here), but my guess about what is happening here is this:

• Any given Whoogle instance collects search queries from potentially all over the world and sends them off to Google from a single IP. That is just kind of the nature of using any kind of proxy service.

• Google has put up a mechanism that automatically throttles requests coming from IP addresses that exceed a certain number of queries. This is called “ratelimiting”. If you are using straight-up Google on your laptop or whatever (with your own IP) it is essentially impossible to hit this threshold, but with tons of people using the same Whoogle instance at the same time sometimes the threshold is exceeded and the ratelimiting kicks in.

• To work around the ratelimiting problem, at some point whoever maintains the Whoogle instance set it up so ratelimited queries can be passed to Farside. Farside is almost like a network of public instances (Whoogle, or other stuff too) that can self-identify where ratelimiting is happening and help pass your query to somewhere it can get through.

• My theory is that Farside needs to use some kind of cookie data for this process to work correctly.

I’m guessing the very aggressive cookie settings the Firedragon browser defaults to may be preventing the handoff of the search query in the event that your search is ratelimited.

[FGD]

@BluishHumility

is that Fireside needs

You mean Farside. Too much "Fire"dragon, hey.

[BluishHumility]

@FGD lol Fireside!

Sit down, put your feet up and let me tell you all about my Whoogle instance...