Why wouldn't app developers stuff their GET requests?

This attack is not “Request as many files as possible while the app is open”.

This attack is “I’m an app developer and I want to get paid more for my app so I’ll triple the size of all images from 300x300 to 900x900.”

How the hell is anyone going to claim fraud against that? “Don’t use higher quality images”…?

This sums it up beautifully.

If that means share more info of higher quality then it’s good. If it is for no user purpose then it may be detected and fail IMO.

3 Likes

I disagree that request stuffing will be inherently disincentived by its inefficiency for users. First, it costs users nothing, so battery drain and bandwidth are much harder to quantify and care about. Second, users have proven they can be pushed around and have no backbone–look at any major website today proudly serving spyware, ads, malware, and sharing data with gov’ts. Third, app developers and content creators will eventually justify their request stuffing as a way to provide ‘free’ apps to users, and then guilt trip users into allowing such behavior–again see any of the major sites today bemoaning ad blockers.

3 Likes

In that case, it would be more of a “screw this app, it’s slow and it’s taking up too much GBs” type of thing.

2 Likes

@zankfrappa has it exactly right.

  • Users won’t care
  • It won’t interfere with the app.
  • It doesn’t cost them safecoin.
  • Nobody tracks their bandwidth, let alone on a per-program basis.
  • Additional power cost is negligible
  • It will be hard to detect
  • If it is detected, it will be easy to rebuttal

@dirvine I’ll admit I’m surprised you think anyone would stop using an app just because they presume it’s GET-stuffed. They have no reason to care.

You misunderstand. This is not a “Let me spread my spam app and have people run it for a few minutes-hours at a time” problem, which in that case yeah if the app has no value no one will use it.

The real problem is: “Me and 3 developers made an app that now has millions of users, it’s our full time jobs, and now we’re going to double the GET requests by loading extra video resolutions to double our income.”

The incentive is huge with no downside when nobody realizes it’s happening or has any reason to care, let alone to actually stop using their safe-instagram app.

It would be unnoticeable. Imagine as you read this right now your browser is making requests in the background (it probably is btw). These extra GETs do not stall the page scrolling or videos playing. And it only starts once all real page resources are downloaded.

The page loads normally and shows no signs of extraneous requests.

1 Like

A little confusing read here…

If the application does tons of GET requests, well then that would definitely slow down the mainline activity. So it can not be unnoticable, and I’m confused on how can it go unnoticed the extra GETs

Second, if someone app developer designed code that is doing useless GETs, and it’s solely a “GETTER” application, then people can make that clear.

Third, devs should be focusing on making a better application, versus trying to do more GET requests.

Fourth, I think it won’t be ultra easy to make an application that always is GETing unique data because it needs to discover it somehow.

Fifth, with an increasing in size network, the caching should provide a thick enough cushion so that “by the several-th GET request, no further coin is awarded”

Sixth, after doing some calculations, I’m not sure that there will SO many Safecoins to expect per application, in otherwords @janitor and @backseat, you likely are not to get filthy rich just you two spamming GETs into Safe Network, I’m sure you will get some coins though, I calculated that even if you made an application as robust in GET requests as the forum, (400k page views per month) you still would make less than 40,000 Safecoins after a year. So if everyone made an application with 400k unique requests it would still only be few Safecoins compared to the whole.

Seventh, based on the above there is plenty of visible cushion, and it seems suitable for good reasons.

5 Likes

Or just: how can I split my data in order to maximize my Get counts?

I understand the intent; creating an automatic revenue scheme for app developer. That sounds interesting indeed. But done this way, I think it puts the interest of the app developer at odds with the interest of the user and of the network itself.

1 Like

Doubling GET requests when the app has millions of users will not necessarily double the Safecoin returns because other applications are also GETing.

3 Likes

Maybe not, but since there’s no reason to not do it you can be sure it will be done. Even if it’s just an increase of 5%, the effect will be very real for the network and no value as been added to the user.

2 Likes

If you need to read 2 files instead of one, you’ve reduced performance. What’s missing there? Increasing GETs can be done, and you’d be welcome to do so. But you won’t get more Safecoins. Increasing GETs by 5% is not giving you 5% more Safecoin just like doubling doesn’t give you 100% more Safecoins.

Then you slow down the users’ experience. Most people will not want to use slowed down applications when better ones are available and approachable. Especially if they know they are available.

4 Likes

Of course, I agree. But the name of the game becomes: how far can I push my get request count before I start losing users. 5% more might not mean 5% more Safecoin but it it means 1%, or just 0.5%, there no reason I shouldn’t do it. The effect won’t be noticeable to the user. But rest assure everyone will do it.

It pushes app developer to become Get Request Maximizer Expert. A title no one is exited about I’m pretty sure.

3 Likes

You’ll start losing users faster by not adding features and focusing on how to steal more coins with extra get requests.

Chasing after %0.5 will cost you 100% when people start using better applications while you’re focusing on squeezing out %0.5 increase in your decreasing Safecoin earnings.

This Get Maximizer activity will push an app developer to Lose users and trust. It’s not a title people will get unless they want to waste their lives.

2 Likes

Well, you just need to look at the current state of ad revenue to see to what extend people are ready to “waste” their life in order to squeeze some extra profit. I think it will be done a lot.

You can even make a library that splits the data for you. Once it’s coded, you can just reuse it in all your project, no extra effort needed.

2 Likes

Anyway, my point is. It will be done, how much it will effect the network is up to speculation but to think this scheme as no effect at all on the network is pretty naive. I think with every awesome thing the network as to offer it’s really not worth it and even necessary.

To conclude, I can’t resist hoping for the reward to be on the PUT request instead, but sadly, that doesn’t seems to be in the pipeline. Oh well…

2 Likes

maybe to the advantage of others (so no this is not a solution to scamming Safecoin through GET requests you’ll have to pay the price):

I defer…

2 Likes

It would be interesting to do some analysis on the “benefits” that an APP builder would gain.

As far as those who provide higher resolution images for the user, would be judged by the user as to its usefulness. It could even be seen as an upgrade.

Exactly how much an APP builder gains by doing useless gets to increase profit would need to be examined. Too much and caching would reduce this a lot (avalanche effect means that once enough gets are happening earnings actually reduce again). It would seem to be a case of diminishing returns. In other words there would be a “sweet” spot where earnings are maximised. Of course if the # of gets is too high then users will notice and leave room for another to produce a much leaner APP that suits them better.

We will have people gaming the system where ever they can. The trick is to identify where it affects the network operations/economy in a significant way. Then work on fixing those and leave the others to the losers who think they are gaining a lot. Much like what happens in the real world, just that it should be more successful fixing the significant issues in SAFE then they have in the real world.

1 Like

Hey @dallyshalla let me walk through your response to clarify a few things for you.

[quote=“dallyshalla, post:26, topic:5563”]
If the application does tons of GET requests, well then that would definitely slow down the mainline activity. So it can not be unnoticable, and I’m confused on how can it go unnoticed the extra GETs[/quote]

It would not slow down any activity and an app developer wouldn’t even have to hide it.

Let’s say the app is a website. The app requests all the page data. The images, stylesheets, scripts, etc. That’s the “legitimate” GETs.

After the page is loaded and the DOM is rendered, THEN the app starts calling “additional data”.

AJAX scripts run constantly in the background of your browser, and it’s quite rare that you notice a performance drop from requesting new data. The DOM is already rendered, there’s nothing changing, it doesn’t have to be re-rendered, and so page scrolling and everything work perfectly with background requests.

Furthermore, the app developer doesn’t have to hide it. He loads the “legitimate” data, and then has a script load “accessory-data.js”, which downloads actual images/video of a higher and lower resolution.

This accessory request doesn’t cost any safecoin and will be unnoticeable as it’s downloaded in the background, and because it’s never actually added to the webpage, the DOM never re-renders as well.

If someone calls him out on why his app/website is downloading these big files in the background that aren’t being used, he just says “Those are the alternate resolution videos pre-cached. 40% of users change the resolution on my app and if they make that choice I want them to have a seamless transition to their choice resolution”.

He’s just trying to make his app better for people (lies), but what are you going to say back to that?

[quote=“dallyshalla, post:26, topic:5563”]
Second, if someone app developer designed code that is doing useless GETs, and it’s solely a “GETTER” application, then people can make that clear. [/quote]

The problem is not purely “GETTER” applications.

The problem is when legitimate apps with actual value suddenly decide to push an update that adds a significant amount of more GETs, so the app farms more safecoin.

And Nike should be focusing on treating their Malaysian factory workers well, but that’s terrible business economics.

As part of the SF POD you must realize how easy it would be to load accessory resources?

<script>
var files = ['safe://video-732-480x360.mp4', 'safe://video-720x480.mpf', 'safe://video-1024x720.mp4'];
for (a=0; a<files.length; a++) {
    var accessory = document.createElement('link');
    accessory.href = files[a];
    accessory.rel = 'preload';
    
    document.getElementsByTagName('head')[0].appendChild(accessory);
}
</script>

Takes maybe 10 minutes for even the most inexperienced developer.

This attack is a legitimate app with users uploading and storing actual data. The app could load other user’s public photos in the background, not that difficult.

Not to mention it only has to load ANY public chunk to get the farm request, it doesn’t have to be data created by the app itself.

Only that chunk would be thoroughly-cached across the network, so what?

There is a constant supply of fresh chunks from the apps’ users, as well as other publicly GET-table data.

I hope you realize that at the most there is minimal cushion, and that this is cause for concern.

2 Likes

[quote=“neo, post:36, topic:5563”]
It would be interesting to do some analysis on the “benefits” that an APP builder would gain.[/quote]

Remember economics class: Raise the cost to maximize revenue? Raise the cost too little and you’ll not hit your maximum revenue. Raise the cost too much and the amount of customers leaving offsets the increased revenue per customer.

The trick is to slowly add more in each app update over time, and don’t stop until the update where your total revenue starts to fall from the same quarter last year.

It works even better when your customer has no idea they’re paying more.

If app makers can make enough to make a living, they will of course profit significantly off of additional GETs.

This would require a different frame of mind than usual development:

1st. You can load more than a computer can handle. Performance does matter, with 30 tabs open, I won’t be visiting that website donwloading the internet in the background.

2nd. If all the app devs are thinking about GETs they’re going to wind up GETing eachothers’ data eventually it all goes to cache. If the network is small and you make an app that gets everything, eventually youll get everything to the point that nothing generates farming rewards anymore.

3rd. The return to the developer is only if the coin goes to $2.00 and while possible, it is just fantasy.

In reality devs will likely not see themselves making 1 million safecoin per application they make, more like 1,000 Safecoin. And that means regardless of the USD or whatever value a Safecoin is traded for. So the concern is much less because what I’ve gathered is that there is a group of people with the pursuit of trivial 10 minute applications that rarely people will use.

And loading all the formats for fast response time is a legitimate use case, but also I’m sure that the person loading 10 movies in a DOM or even 1000 Movies in the DOM is going to crash the browser before you get there, and people will realize not to visit that site again.

I think this discussion is valuable to reveal anything else that might interfere.

App developers will profit because there are many people using applications. And that comes with perceived value. Also, app developers making GETs will cause more farming rewards for farmers. So this is an essential activity that will be regulated with Cache, and the absurd applications that have no utility to people but lots of GETs won’t even see those GETs so…

I think also one must put themselves in the mindframe that there will be more than just one person making applications, and yes applications will spit out Safecoins and for all the devs, if you can write that code snippet you posted then congrats you too will get some safecoin whether you get a lot or a little…

@dallyshalla I don’t really know what you’re arguing, you kind of just reiterated what you said above.

What kind of processing power do you think is required to purely save the data chunks? That’s all that has to be done.

And even then you don’t have to download 16 extra video files on one page click. The page is loaded and after a second it loads the SD version, after that’s done the HD…

I sincerely don’t understand what part of this attack you think will effect performance to any noticeable degree. It could be described as “business as usual” because all it does is request files in the background like 75% of all apps/websites, but takes advantage of getting paid for it.

Again let me explain it.

The attack is from a legitimate app.

Mr. X has made an app, and over 6 months it got really popular and now 100,000 people use it.

Suddenly, Mr. X decides to push out an update to his app that has it making 3x the GET requests than it used to.

He does this purposely to make more money.

All these new GET requests are supposedly to pre-cache videos that will display in the “Most recent user uploads” in the sidebar of his app.

Or at least that’s what he tells anyone who asks about it.

But these videos are rarely shown, they are only downloaded in the background for possible use.

Because these videos are always the most recent user uploads, they’re always fresh and uncached.

On every page request the user is GET-ting the newest videos silently.

The app has 4-5 video uploads per minute. Enough fresh content to not worry about caching (even if the whole video is cached network-wide, after 15 seconds there’s a new video).

What?

The developer didn’t invest anything extra to GET-stuff his app, the return is day 1 after he pushes the app update because he immediately makes more safecoin than he was before with no additional cost.

What do you mean return is only at $2.00? I have no idea what that means.

Again, please share your maths.

Are you trying to argue that this attack is not viable because app developers will never earn enough safecoin which will never be valuable anyway?

I’m not sure what I’m reading anymore.

Again you’re showing me you don’t understand the attack vector.

True. But that’s not the problem.

The problem is when developers of popular apps discretely start “pre-loading” data at a rate of 4-5x what they were weeks before.

Sure it’s not 4-5x profit but of course they will definitely farm more.

Also, again, loading the file and rendering it to the DOM are completely different concepts.

I think it’s obvious your oversight is frustrating the hell out of me.

App developers get paid on GET requests. If app developers profit because many people use their applications, it’s ONLY BECAUSE those people are making GET requests. If the app developer has every single person make more GETs, he will get paid more.

Seems like you need a look over the broken window fallacy @happybeing brought up earlier.

The network is losing resource because of GET-stuffing. The value loss is permanent. Google “broken window fallacy”.

That’s literally the whole reason this matters.

Like I mentioned above it won’t.

Again, not the attack vector I’m worried about.