Jamie's Space

DEV375: Reactive Programming – Ivan Towlson

• History of developing for windows clients
  • Win16/Win32 – Procedural style (message loops)
  • ActiveX/Visual Basic – Limited OO style, events + components
  • Windows Forms – Component oriented style
  • Common themes
    • Write code to copy data from model to control
    • Write code to detect changes in control data
    • Write code to copy data from control to model
    • Detect changes in model data or use gatekeeper
• What is better about WPF/Silverlight?
  • Enhanced component model encapsulates common plumbing.
  • Designer-developer workflow needs a declarative programming style to work well.
  • Hard to write robust OO/procedural code against a lookless model.
• Reactive programming is like binding values together. Think like how you can create formula’s in Excel – changing the value of one of the cells in a formula updates the result of the formula, and it keeps doing it.
• Benefits
  • Remove plumbing code, no need to track changes in model and controls and copy data between
  • View/model relationship expressed in view instead of in controller/presenter code. Express the what, not the how.
  • Works well with the lookless approach – view reacts to model change, rather than the model manipulating the view.
• .Net works on a notification system (INotifyPropertyChanged) – when something changes, dependent values re-evaluate themselves.
• Issues
  • We need to react to changes to derived data -> use converters for this.
  • A reactive expression may produce unacceptable values (user input?). Solution is to use validation.

Bindable LINQ

• How do you query an ObservableCollection? How do you observably query an ObservableCollection?
• LINQ queries don’t provide change notification!
• Bindable LINQ is a community project to enable reactive controls to back easily onto LINQ queries
• Key API : AsBindable() – extension method on IEnumerable<T>

SEC201: Do These Ten Things or Get Own3d – Steve Riley

1. Use precise terminology

• Vulnerability – The problem
  • Code
  • Configuration
  • Circumvention – Security rules that are so draconian that they encourage people to actively try to get around it.
• Threat – The person that carries out the attack
  • External
  • Internal
• Exploit – the code that exploits the vulnerability
• Exposure – The cost of the attack being carried out.
• Risk

2. Accept that no one will like you

3. Think like a bad guy

People will not like you for this either.

4. Understand the science

• Identity is not Authentication.
• Encryption is not Integrity
• Inspection is not Intent – Can’t tell intent by looking at someone’s stuff.
• Secrecy is not Trust – just because you can make something a secret, doesn’t mean you can trust it.
• People are not Technology – All the technology in the world will not solve your technology problem.
• "Defence in depth" = "I am a parrot"
• Stupidity is not Malice
• Usability and Security are a tradeoff.

5. Protect your gear

• Patch your stuff.
• Use the firewall.
• Don’t run as admin, or reduce number of admins.
• Install anti-malware, or scan fileshares.
• Don’t tweak.
• Rebuild, don’t disinfect.

6. Swallow your pride

• Read up
  • Microsoft
  • www.sans.org
  • www.securityfocus.com
  • http://searchsecurity.techtarget.com

7. Reconsidering the laws

• Law 1: If a bad guy can persuade you to run his program on your computer, it is not yours anymore.
• Law 2: If a bad guy can alter the operating system on your computer, it’s not yours anymore.
• Law 3: If a bad guy has unrestricted physical access to your computer, it’s not your computer anymore.
• Law 4: If you allow a bad guy to upload programs to your website, it’s not your website anymore.
• Law 5: Weak passwords trump strong security.
• Law 6: A computer is only as secure as the administrator is trustworthy.
• Law 7: Encrypted data is only as secure as the decryption key.
• Law 8: An out of date is only marginally better worse than no virus scanner at all.
• Law 9: Absolute anonymity isn’t practical, in real life or on the web.
• Law 10: Technology is not a panacea.

8. Classify, and classify again.

• Access
  • Principle of least privilege – others and yourself. If this principle interferes with your business process and is part of the OS, email Steve.
• Data
  • Confidentiality, retention, recovery.
• Trust
  • Functions, directions.

9. Don’t let your guard down.

• People are always trying to sell you silver bullets/snake oil.
• Trustworthy people will discuss the downsides of their software

10. Protection, not restriction.

In: Useful Information | | #