Coupon Codes are invalid almost all the time

[CyberCatStudios]

When I started using Syrup, I went on to Amazon to apply codes. None of the codes work, and there's a clear reason for this. The bot scrapes codes from the internet, but not necessarily accurate coupon codes. Websites like groupon.com use bots to push fake coupon codes to their website to boost revenue, since more codes is more time spent watching the page which is more ad revenue. A fix for this could involve blocking certain websites, or testing the validity of code from certain websites.

[Abdallah-Alwarawreh]

High chance yes, its because i have to grow to build connections with big companies to do partner ships for them and put them on recommended and show top coupons

I will also think about making a tester for validity. and i will try user submissions.

[pixDeVl]

When I started using Syrup, I went on to Amazon to apply codes. None of the codes work, and there's a clear reason for this. The bot scrapes codes from the internet, but not necessarily accurate coupon codes. Websites like groupon.com use bots to push fake coupon codes to their website to boost revenue, since more codes is more time spent watching the page which is more ad revenue. A fix for this could involve blocking certain websites, or testing the validity of code from certain websites.

Working on validation of codes will definitely be useful moving forward, if annoying because it would need to be manually written for all sites, but maybe getting codes from multiple sites and prioritizing ones that repeat would help?

[NIDNHU]

one way you can test the code is similar to other extensions by just auto applying the codes at the checkout to make sure it works. another way to do it if that would be too difficult is to have a crowdsourcing style system where people can vote for different codes to push them to the top of the list and sort them based on newest, most liked, most off, etc.

[BloomyInDev]

High chance yes, its because i have to grow to build connections with big companies to do partner ships for them and put them on recommended and show top coupons

I will also think about making a tester for validity. and i will try user submissions.

then it will be the same as honey

[furdiburd]

Validation could work with a reputation system. If a coupon code works the user can upvote it if it didn't then downvote. The higher the vote amount is the higher it will be ranked in the codes.

[Abdallah-Alwarawreh]

Yeah, we're working on that atm. will push an update soon

[PlayzAe]

You can create a list of blocked domains or websites that are known to host fake or unreliable coupon codes like Groupon
Also for each coupon code retrieved, test its validity but this maybe impossible because I don't think sites like amazon make that type of API public but you could add a "Report Invalid or Valid" button for each code displayed. Log them in a database, and prioritize filtering codes
I also notice your code doesn't have a backend, btw I know little of typescript
Also where can I change to modify the code for the scrapper to get my local stores around me?

[bappitybup]

High chance yes, its because i have to grow to build connections with big companies to do partner ships for them and put them on recommended and show top coupons

I will also think about making a tester for validity. and i will try user submissions.

@Abdallah-Alwarawreh

on the topic of user submissions:
I think you should implement it in a similar fashion to how sponsorblock does voting on segments. so users can upvote/downvote submissions:

• if the submission score (the sum of upvotes and downvotes) is -2 or lower, it would hide it from view.
• more info on the sponsorblock voting system here: https://wiki.sponsor.ajay.app/w/FAQ

[Abdallah-Alwarawreh]

thanks i will keep this in mind

[MyFedora]

I'd like to point out how other browser extensions that aggregate a lot of data handle this kind of stuff. Viewstats, for example, uses its browser extension to find new YouTube videos, but it doesn't trust the data provided by the client, even though there's no real incentive for users to falsify it.

Now, contrast that with the situation we're dealing with, where companies are financially incentivized to submit and upvote invalid coupon codes and downvote valid ones. In this case, relying on client-side data becomes a serious vulnerability. Without a critical mass of legitimate users to proactively outvote the bots, the whole extension becomes worthless.

Proposal 1: A server-side approach to coupon validation, possibly using residential proxies, seems like a more robust solution. This setup also eliminates the issue of aggregating services promoting invalid codes for the sake of ad revenue. I get that implementing something like this can be a significant cost, and that's a totally valid reason to avoid it.

Proposal 2: Alternatively, automating votes when a coupon is successfully applied could help boost the number of legitimate votes from users who otherwise wouldn't participate. This could help balance out the bot activity and make the system more resilient. It's also a lot less expensive to implement.

Proposal 2 should also come with shadowbanning users who repeatedly submit invalid codes, but also take into account that some users might only post bad codes for one site and valid ones for competitors. There's also the potential to give trusted users the ability to directly whitelist or blacklist codes.

At a small scale, a voting system might be good enough, but the potential for abuse grows as the extension grows in popularity. It's one of those cases where we need to plan ahead, anticipate the problem, and have a strategy in place to pivot when the time comes.

[Abdallah-Alwarawreh]

Hmmm, maybe we need to setup optional login for voting so we can actually ban fake votes/spammers

[mvlwarekekw]

we'd definitely need some type of unique identifier to avoid any spam

[MitjaCH]

You could use a UUID-based or hash-based ID, where a unique identifier or a secure hash is generated from device/browser properties when a user first installs the extension or visits the site.

This ID can then be stored locally in the browser's local storage.

To "ban" fake votes/spammers, you could implement a reputation system where votes from new client IDs are initially "weighed" less and gradually gain more weight after multiple valid submissions.

If a user repeatedly submits fake or invalid votes, you can shadowban them (their votes will appear valid locally but won’t affect the system).

[ImGajeed76]

@MitjaCH That's a good idea, but also difficult to implement. How do you make sure that the generated hash is actually from that user and not just some random hash?

Also, speaking of voting. My backend (the current syrup backend discountdb) uses a voting system where more recent votes are valued more, and there are also rate limiters to prevent spamming. I know it's not perfectly secure, but it works without login, and that's an advantage for UX.

[MitjaCH]

@ImGajeed76 To address this concern, I'd suggest the following approach to make the generated hash more reliable:

Device Fingerprint Components: Instead of a simple hash, you could generate the ID using a combination of:

• Browser user-agent
• Screen resolution
• Installed plugins/extensions count
• Local timezone
• Random salt for uniqueness

These factors make the ID harder to replicate. However, it's important to avoid collecting too much data to stay compliant with privacy guidelines. Also, I believe a primary goal of Syrup is to collect little to no data.

Ephemeral Salt System: To ensure the hash cannot be easily copied, you can generate a random salt per session and combine it with the static properties. This makes spoofing more difficult since the combination changes with each visit.

Regarding your current voting system:
I really like your approach of valuing recent votes more and using rate-limiting to prevent spam it balances security and usability well.

One idea to improve the system without requiring logins:
You could introduce a "vote decay" mechanism, where a user's initial impact is reduced if too many votes originate from similar fingerprints within a short time.

[MitjaCH]

Regarding Implementation Difficulty:

You're right the implementation of such a system would be challenging since it would be quite complex, especially considering privacy regulations. Additionally, maintenance could be an issue, as device properties (like user-agent strings) may change over time.

However, in my opinion, the complexity outweighs the benefits. I could start with a more basic system using only non-sensitive properties (e.g., user-agent and a random unique ID) and iterate over time.

[ImGajeed76]

I just got a crazy idea that could work well and would be private:

There should be an endpoint like /syrup/register that returns a UUID that isn't yet used by anyone. This functions as user-identification. This UUID also shouldn't be shared with anybody.

With this UUID, you can vote on coupons and at first, your votes don't have a massive impact. But from time to time, if you make good votes (I don't know how to tell that yet, but I will get an idea) your impact gets bigger.

[mvlwarekekw]

seems like a possible option to me, which should work pretty well

[MitjaCH]

Regarding your point, @ImGajeed76, I agree that this could align well with an impact-based reputation system. The idea would be to track vote accuracy and adjust reputation accordingly if the user's vote is accurate, their reputation increases; if not, it decreases.

[ImGajeed76]

Thank you, @MitjaCH, for bringing me to this idea!

[Abstra208]

@Abdallah-Alwarawreh you can close this