News for hackers. Stuff that matters.
Re:Coding in the open: how to do it securely by dest on Wednesday September 27, 2017 @09:18AM (#15347482)
OK with public code, but with limits, some data and code should be closed [1], including:

    keys and credentials
    algorithms used to detect fraud
    unreleased policy
[1] https://www.gov.uk/government/publications/open-source-guida...
Re:Coding in the open: how to do it securely by dangerface on Wednesday September 27, 2017 @09:39AM (#15347664)
I get the others but why "unreleased policy"? The public will find out what the policy is so whats the point?
Re:Coding in the open: how to do it securely by Ensorceled on Wednesday September 27, 2017 @09:57AM (#15347818)
It's essentially insider trading to know policy before the policy is released.

In Canada, Tax Policy Changes take effect from the day the bill is introduced to Parliment or published for discussion for exactly this reason.

Re:Coding in the open: how to do it securely by panarky on Wednesday September 27, 2017 @12:20PM (#15349330)
It's not insider trading if the information is public.
Re:Coding in the open: how to do it securely by Nomentatus on Wednesday September 27, 2017 @04:07PM (#15351792)
Yes, it can be, and I believe convictions show this - if public means "someone else could have stumbled on the info, in theory" but you were specifically tipped off where to go and when in exchange for cash; which is the kind of worry here.

But as well, policy discussions that allow no privacy tend to be very circumscribed.

Re:Coding in the open: how to do it securely by PeterisP on Wednesday September 27, 2017 @11:08AM (#15348500)
For tax policy, it would make sense to solve this problem in the entirely opposite way - i.e. declare that any tax policy changes cannot take effect faster than the next fiscal year; it's also fair and much more reasonable.
Re:Coding in the open: how to do it securely by hinkley on Wednesday September 27, 2017 @12:25PM (#15349390)
Let's say they decide to put a tarrif on something a lot of people hate or think problematic. Let's say for argument's sake, 2 stroke generators. But they have a lot of power (and users) so you don't think you can swing a yearly tax. But a tax on new purchases/builds might be tractable. They get to keep all the existing ones but they can't build more. That's grandfathering.

If you give the wrong people to the end of the year, they'll grandfather in as many as they can, even if they sit unused. So now you're putting off curbing the installed base and instead you've actually created a glut. Now your tax will have zero net effect for four or five years and will make things (say, smog) far worse in the short term.

Re:Coding in the open: how to do it securely by SomeStupidPoint on Wednesday September 27, 2017 @12:47PM (#15349658)
It can actually end up unwinding your tax (or regulation) --

If the people rushing to buy up the supply to simply store them off-line happen to cut off people who need them for what are sensible and essential reasons, you end up with a litany of cases of the tax causing problems paraded about as it comes into effect, and it ends up repealed or undercut because of political pressure.

(Usually 1-year window extended because "we need more time to phase it in" and by the time the second window would close, it's gutted.)

It's not just that it can end up counter productive in the short term, it's that it can undercut itself as a law as well by destabilizing a market that usually has low, but important volume.

Re:Coding in the open: how to do it securely by KGIII on Wednesday September 27, 2017 @01:15PM (#15349971)
In some places, laws already work sort of like that. Except for emergency bills, they can't take effect until something like 180 days after congress has had their final session.

It makes perfect sense, to me at least, for taxation regulations to be the same. Of course, they'd probably just default to calling all rule changes emergencies...

Sort of related: I love the idea of paying taxes. Mine are prepared and filed as soon as I can do so. I have a great time paying my taxes, to the point where I bring a bottle of wine and flowers to my accountant. But, man, I really hate the complexity and how the money is spent.

Anyhow, maybe they should only make rules for the first half of the year and then none of the changes go into effect until the first day of the year? I like your idea.

Re:Coding in the open: how to do it securely by blibble on Wednesday September 27, 2017 @07:46PM (#15353376)
UK politicians would find that far too restrictive!

nearly every Budget affects duty on things like beer and petrol, and go into effect at midnight

people know to fill up their car the night before!

Re:Coding in the open: how to do it securely by hardlianotion on Wednesday September 27, 2017 @09:52AM (#15347783)
To prevent a chilling effect on in-depth analysis of policy options before they are finalised. I think this is a good thing.
Re:Coding in the open: how to do it securely by rahkiin on Wednesday September 27, 2017 @09:43AM (#15347696)
Maybe it is unfinished. To prevent a media backlash over non-final policy.
Re:Coding in the open: how to do it securely by swsieber on Wednesday September 27, 2017 @02:44PM (#15350961)
A prime example of this would be the writing of the constitution of the U.S. It would have been dead in the water if the public was at those meetings.
Re:Coding in the open: how to do it securely by asfdsfggtfd on Wednesday September 27, 2017 @09:42AM (#15347689)
What is the advantage of obscuring the algorithms used to detect fraud? (I.e. is this not just security by obscurity?)
Re:Coding in the open: how to do it securely by ReverseCold on Wednesday September 27, 2017 @09:46AM (#15347723)
Fraud/spam detection algorithms have to be security by obscurity, or someone can just check if what they're doing trips the algorithm and then not do that.
Re:Coding in the open: how to do it securely by fghtr on Wednesday September 27, 2017 @10:01AM (#15347846)
I would compare such obscurity with secret laws that you are not allowed to break. It opens up a possibility for selective enforcement.
Re:Coding in the open: how to do it securely by marcosdumay on Wednesday September 27, 2017 @10:46AM (#15348277)
Fraud detection can be sagely done in obscurity, as long as any enforcement action is done on the open.

Filtering data to find who is breaking a law is different from the law itself and from penalizing people.

Re:Coding in the open: how to do it securely by theoh on Wednesday September 27, 2017 @01:58PM (#15350468)
If you use an opaque machine learning technique to detect fraud, for the purposes of probity some kind of "parallel construction" could be employed to give a public exlanation; it's surely important to explain and justify to the humans involved. The analogy is with the person of a particular ethnicity who is always getting pulled over by the cops. This must be made transparent.
Re:Coding in the open: how to do it securely by marcosdumay on Wednesday September 27, 2017 @02:47PM (#15351004)
You don't need "parallel construction". You need to inform it was detected by some opaque means, and that you proceeded to verify it with a transparent and legal procedure.

What you can't do is detect it by opaque means and then proceed to sanction people or even gather some too elevated investigative powers.

Re:Coding in the open: how to do it securely by theoh on Wednesday September 27, 2017 @04:30PM (#15351998)
The act of verification (of suspected fraud) is not costless to the various parties involved. So say I keep getting inconvenienced by this verification because of my behaviour ("was it really you who made this request?") then someone should be accountable for all those false positives. "Parallel construction" creates an accountability. I know it usually means something more sinister -- but just symtactically it's a good description of the requirement.
Re:Coding in the open: how to do it securely by marcosdumay on Wednesday September 27, 2017 @05:25PM (#15352489)
I do think we are trying to say the same thing. When I say that no unreasonable additional power should be gained by such detection, I intend that between a few things that the verification should not be costly to the investigated party (costs should be only on the investigators). Looks like you are naming that verification "parallel construction", and so, I do agree.