|
|
martes, 5 de mayo de 2020
October 2019 Connector
$$$ Bug Bounty $$$
What is Bug Bounty ?
A bug bounty program, also called a vulnerability rewards program (VRP), is a crowdsourcing initiative that rewards individuals for discovering and reporting software bugs. Bug bounty programs are often initiated to supplement internal code audits and penetration tests as part of an organization's vulnerability management strategy.
Many software vendors and websites run bug bounty programs, paying out cash rewards to software security researchers and white hat hackers who report software vulnerabilities that have the potential to be exploited. Bug reports must document enough information for for the organization offering the bounty to be able to reproduce the vulnerability. Typically, payment amounts are commensurate with the size of the organization, the difficulty in hacking the system and how much impact on users a bug might have.
Mozilla paid out a $3,000 flat rate bounty for bugs that fit its criteria, while Facebook has given out as much as $20,000 for a single bug report. Google paid Chrome operating system bug reporters a combined $700,000 in 2012 and Microsoft paid UK researcher James Forshaw $100,000 for an attack vulnerability in Windows 8.1. In 2016, Apple announced rewards that max out at $200,000 for a flaw in the iOS secure boot firmware components and up to $50,000 for execution of arbitrary code with kernel privileges or unauthorized iCloud access.
While the use of ethical hackers to find bugs can be very effective, such programs can also be controversial. To limit potential risk, some organizations are offering closed bug bounty programs that require an invitation. Apple, for example, has limited bug bounty participation to few dozen researchers.
A bug bounty program, also called a vulnerability rewards program (VRP), is a crowdsourcing initiative that rewards individuals for discovering and reporting software bugs. Bug bounty programs are often initiated to supplement internal code audits and penetration tests as part of an organization's vulnerability management strategy.
Many software vendors and websites run bug bounty programs, paying out cash rewards to software security researchers and white hat hackers who report software vulnerabilities that have the potential to be exploited. Bug reports must document enough information for for the organization offering the bounty to be able to reproduce the vulnerability. Typically, payment amounts are commensurate with the size of the organization, the difficulty in hacking the system and how much impact on users a bug might have.
Mozilla paid out a $3,000 flat rate bounty for bugs that fit its criteria, while Facebook has given out as much as $20,000 for a single bug report. Google paid Chrome operating system bug reporters a combined $700,000 in 2012 and Microsoft paid UK researcher James Forshaw $100,000 for an attack vulnerability in Windows 8.1. In 2016, Apple announced rewards that max out at $200,000 for a flaw in the iOS secure boot firmware components and up to $50,000 for execution of arbitrary code with kernel privileges or unauthorized iCloud access.
While the use of ethical hackers to find bugs can be very effective, such programs can also be controversial. To limit potential risk, some organizations are offering closed bug bounty programs that require an invitation. Apple, for example, has limited bug bounty participation to few dozen researchers.
Related word
viernes, 1 de mayo de 2020
Ten Ideas From Reiner Knizia About Playtesting
Reiner Knizia is one of the biggest names in game design around the world. The German game designer is a mathematician and has his name associated to more than 700 games launched in many different countries. I had the honor to talk personally to Knizia in 2011, at DIGRA's conference in Hilversun (Netherlands) and I watched a great keynote about the game designing process in the same event.
On that occasion, I gave Knizia my board game, YN, and had the opportunity to talk a little bit with him (a great achievement for my game designer career).
I follow Knizia in social media and I'm always taking notes about the knowledge on game design he shares on those platforms. In this post, I will reproduce 10 ideas Knizia showed recently on Twitter about playtesting (one of the most fundamental topics in the game designing process). Below, I listed the 10 points. Follow him by clicking here.
Playtesting 1. Those who do not play do not live. Those who do not playtest do not design.
Playtesting 2. Designs always work perfectly in your mind. The first playtest is the (often cruel) moment of truth.
Playtesting 3. Regardless of how much experience you have, you cannot develop a game on the drawing board – only at the playing table.
Playtesting 4. Game design is a classic iterative process of playing and improving – nowadays popularised as "design thinking".
Playtesting 5. When your playtesters do not like your design, (usually) your design is to blame – not your playtesters.
Playtesting 6. I recognise good playtesters by my (frequent) urge to strangle them.
Playtesting 7. For your design to appeal to one group, test with one group. For your design to have broad appeal, test with many groups.
Playtesting 8. You can make (most) designs interesting through your play-talk - but when published, your design needs to speak for itself.
Playtesting 9. Blind playtesting, without you taking part, is as useful as other people going on a rollercoaster and reporting their experience.
Playtesting 10. When you have playtested your design to perfection, let it rest some time, then play again. – Expect to be surprised!
#GoGamers
On that occasion, I gave Knizia my board game, YN, and had the opportunity to talk a little bit with him (a great achievement for my game designer career).
I follow Knizia in social media and I'm always taking notes about the knowledge on game design he shares on those platforms. In this post, I will reproduce 10 ideas Knizia showed recently on Twitter about playtesting (one of the most fundamental topics in the game designing process). Below, I listed the 10 points. Follow him by clicking here.
Playtesting 1. Those who do not play do not live. Those who do not playtest do not design.
Playtesting 2. Designs always work perfectly in your mind. The first playtest is the (often cruel) moment of truth.
Playtesting 3. Regardless of how much experience you have, you cannot develop a game on the drawing board – only at the playing table.
Playtesting 4. Game design is a classic iterative process of playing and improving – nowadays popularised as "design thinking".
Playtesting 5. When your playtesters do not like your design, (usually) your design is to blame – not your playtesters.
Playtesting 6. I recognise good playtesters by my (frequent) urge to strangle them.
Playtesting 7. For your design to appeal to one group, test with one group. For your design to have broad appeal, test with many groups.
Playtesting 8. You can make (most) designs interesting through your play-talk - but when published, your design needs to speak for itself.
Playtesting 9. Blind playtesting, without you taking part, is as useful as other people going on a rollercoaster and reporting their experience.
Playtesting 10. When you have playtested your design to perfection, let it rest some time, then play again. – Expect to be surprised!
#GoGamers
Curved Region Rendering
Around a month ago I had an idea in my head: a voronoi grid modified to have rounded cells that change in size. I made an attempt here for single cells changing size. The next step was to merge cells together, as I had done on this project. I decided that the way to demo this would be to simulate some kind of belief/cultural systems that spread over time across a map. I tried this here.
It didn't go well.
What happened? I think the problem was that I had three unknown elements in this project:
- Simulation with the simplest rendering code I could get away with. Figure out what simulation rules are interesting and cool.
- Rendering isolines on a triangle mesh.
- Rendering curved isolines on a triangle mesh, using Bezier curves.
In trying to figure out all three at once, I didn't do a good job on them. I should have instead focused on one at a time. I ended up succeeding with #2 when I learned about and implemented the Meandering Triangles algorithm, and also built a little interactive visualization that helped me understand how the algorithm works. I failed with #1, having tried several algorithms but not finding one that I liked. I realized towards the end of the week that #1 was a red herring; I didn't need a simulation at all, as I really just wanted curved regions. I also failed at #3, having tried some experiments but never finding what I wanted, and also rejecting Chaikin Curves for reasons I can't remember. Since I really wanted the curved variable sized regions, I should have spent more time on #3 and less on #1. I ran out of time on this project so I'll leave #1 and #3 for another day.
You can see the animation I ended up with.
What do I mean "I ran out of time"? That's the next blog post!
Suscribirse a:
Entradas (Atom)
